SRP skickar inte lösenordet i protokollet; det innebär inte att lösenord avskaffas, att nätfiske blir omöjligt eller att verifieraren är ofarlig.
Passkeys och SRP är två olika sätt att autentisera sig. En passkey använder ett nyckelpar och kan ta bort behovet av ett lösenord. SRP är fortfarande lösenordsbaserat, men vid en korrekt körning av protokollet skickas inte själva lösenordet till servern för att bevisa att användaren känner till det.
”Inloggning utan att skicka ett lösenord” är alltså inte samma sak som ”inloggning utan att ha ett lösenord”. Valet mellan metoderna bör grundas på risken för nätfiske, hanteringen av inloggningsuppgifter, återställning och implementationens kvalitet, inte på den allmänna etiketten ”zero knowledge”.
Vad förändrar en passkey?
Vid autentisering med passkeys lagrar tjänsten den publika nyckeln, och användaren bekräftar inloggningen genom att kontrollera den privata nyckeln. Bindningen av inloggningsuppgiften till rätt tjänst och ursprung är en viktig del av metodens motståndskraft mot nätfiske. FIDOs förklaring av passkeys.
Alla passkeys synkroniseras inte nödvändigtvis i molnet. Vissa är bundna till en enhet eller säkerhetsnyckel; andra överförs mellan enheter via leverantören av inloggningsuppgifter. Återställningsmodellen och skyddet vid synkronisering måste granskas för just den leverantören. Enbart ”molnsynkronisering” innebär inte att företaget lagrar nycklarna i läsbar form.
Sessionens säkerhet efter inloggningen är också en separat fråga. En passkey oskadliggör inte automatiskt skadlig kod på enheten eller stöld av en giltig session.
Vad ger SRP servern?
SRP tillhör familjen lösenordsautentiserade nyckelutbyten. I stället för själva lösenordet lagrar servern uppgifter som ett salt och en verifierare, eller verifier. Genom att utbyta protokollmeddelanden kontrollerar parterna kunskap om hemligheten och den gemensamma nyckeln.
Men verifieraren är ingen ofarlig uppgift. Avsnitt 3.3 i RFC 5054 säger uttryckligen att en angripare som kommer över verifieraren kan genomföra en ordboksattack för att gissa lösenordet. Påståendet att ”en stulen databas inte ger någon möjlighet till offlinegissningar” är därför felaktigt.
Ett starkt lösenord, serverskydd, lämpliga parametrar, validering av indata och kontroll av inloggningsförsök behövs fortfarande. SRP garanterar inte heller att sidan där du skriver lösenordet är säker; skadlig kod kan fånga det innan protokollet körs.
En rättvis jämförelse
| Fråga | Passkey | SRP |
|---|---|---|
| Behöver användaren minnas ett lösenord för tjänsten? | Vanligen inte; kontroll över inloggningsuppgiften krävs | Ja, metoden bygger på kunskap om lösenordet |
| Vad lagrar tjänsten för inloggning? | Publik nyckel och tillhörande information | Verifierare och tillhörande parametrar |
| Hur uppnås motståndskraft mot nätfiske? | Bindning av inloggningsuppgiften till tjänsten/ursprunget i FIDOs utformning | Att inte skicka lösenordet i protokollet räcker inte för att göra ett falskt inmatningsfält säkert |
| Är molnet obligatoriskt? | Nej; även enhetsbundna alternativ finns | Protokollet kräver inte i sig en extern identitetsleverantör, men behöver en autentiseringstjänst |
| Hur fungerar återställning? | Beror på typen av inloggningsuppgift och leverantören | Bestäms av kontots och produktens policy, inte av namnet SRP |
Tabellen kan inte användas för en absolut rangordning av alla implementationer. Ett svagt återställningsflöde kan undergräva fördelen med en stark inloggningsmetod.
Hur hänger kontoinloggning ihop med chattnycklar?
Autentisering talar om för tjänsten vem som får agera. Nycklarna för meddelandekryptering avgör vem som kan öppna innehållet. En produkt kan koppla ihop dessa två saker, men sambandet måste vara dokumenterat.
I Livaras säkerhetsdokumentation beskrivs SRP för inloggning, medan återställningspaketet v7 för den krypterade identiteten behandlas separat. Paketet återställer identiteten, inte chatthistoriken. Därför betyder ”inloggningslösenordet är rätt” inte ”alla nycklar och gamla meddelanden har kommit tillbaka”.
Den här artikeln är en konceptuell jämförelse, inte ett praktiskt test av alla Livaras inloggningsmetoder eller en bekräftelse på att produkten exakt implementerar en viss RFC.
Vilka frågor bör man ställa vid valet?
- Om enheten försvinner, vilken alternativ inloggningsväg finns och vem kontrollerar den?
- Är återställningsmetoden svagare än den huvudsakliga inloggningen?
- Hur visas och återkallas okända sessioner?
- Ändrar ett byte av inloggningsmetod meddelandenycklar eller anslutna enheter?
- Vilket konto och vilket oberoende skydd krävs för att synkronisera inloggningsuppgifter?
Sammanfattning: Kalla inte passkeys i sig ”osäkra eftersom de finns i molnet” eller SRP ”immunt mot intrång eftersom det är zero knowledge”. Varje metods gränser och produktens återställningspolicy är grunden för en tillförlitlig jämförelse.
