SRP undviker att skicka lösenordet i inloggningsutbytet; det gör inte en stulen verifierare ofarlig.
Secure Remote Password, eller SRP, låter en klient och server autentisera med ett lösenord utan att skicka lösenordet i det normala protokollutbytet. Det kan minska exponeringen mot en server som annars skulle ta emot lösenordet vid inloggning.
Det tar inte bort alla lösenordsrelaterade hemligheter från servern. Servern lagrar en verifierare, och en stulen verifierare kan möjliggöra lösenordsgissning offline. Den skillnaden är avgörande när påståenden om ”inloggning med nollkunskap” bedöms.
Vad ändras jämfört med vanlig lösenordsinloggning?
I en konventionell konstruktion skickar klienten lösenordet över en autentiserad TLS-anslutning. En väl utformad server jämför en lämplig saltad lösenordshash, undviker att logga inloggningsuppgifter och använder skydd mot gissning. TLS skyddar anslutningen; en lösenordshash skyddar den lagrade autentiseringsuppgiften på ett annat sätt.
SRP ändrar utbytet. Vid registrering upprättar systemet salt och verifierarmaterial. Vid inloggning använder båda sidor färska protokollvärden och sina respektive hemligheter för att etablera och bekräfta gemensamt nyckelmaterial. Klienten använder lösenordet; servern använder sin verifierare. En ärlig klient skickar inte själva lösenordet som inloggningsdata.
SRP-specifikationen i RFC 2945 förklarar protokollets grund. Senare profiler och implementationer behöver få sina exakta parametrar och meddelandekontroller granskade; att kalla en konstruktion ”SRP” visar inte att varje implementationsval är sunt.
| Fråga | Vanlig lösenordsinloggning över TLS | Korrekt implementerat SRP-utbyte |
|---|---|---|
| Tar applikationsservern emot det inskrivna lösenordet vid inloggning? | Normalt ja | Inte som del av protokollutbytet |
| Vilket känsligt autentiseringsmaterial lagras? | Vanligen en saltad lösenordshash | Salt och en lösenordshärledd verifierare |
| Kan en stulen databas möjliggöra gissning offline? | Ja, beroende på lagrat material | Ja, stulet SRP-verifierarmaterial kan möjliggöra gissning |
| Skyddar det mot en tangentbordsloggare? | Nej | Nej |
| Krypterar det meddelandehistoriken automatiskt? | Nej | Nej |
Varför en stulen verifierare fortfarande spelar roll
RFC 5054 avsnitt 3.3 diskuterar uttryckligen stulna verifierare. Det förklarar att en verifierare kan göra det möjligt för en angripare att utge sig för att vara servern och genomföra ordboksattacker för att återvinna lösenordet.
Den viktiga skillnaden är att verifieraren inte bara är en återanvändbar inloggningstoken för klienten. Det gör den inte ofarlig. En angripare kan testa lösenordskandidater mot det stulna materialet i stället för att lösa ett diskret logaritmproblem för varje möjlig hemlighet. Ett svagt eller återanvänt lösenord förblir en allvarlig risk.
Frekvensbegränsningar online kan sakta ned försök mot en aktiv tjänst, men styr inte beräkningar som utförs på en stulen databas. Databasskydd, omsorgsfull lösenordsbehandling och starka unika lösenord är fortfarande relevanta.
Vad SRP inte skyddar mot
En komprometterad ändpunkt: Skadlig programvara kan fånga lösenordet innan protokollet börjar eller stjäla en autentiserad session efteråt.
En skadlig inloggningssida: Om sidan som ber om lösenordet själv är fientlig kan den skicka den inskrivna texten någon annanstans. En webbapplikation behöver fortfarande en pålitlig leveransväg.
Alla återställningsvägar: Ett e-post-, SMS- eller supportflöde som ger kontoåtkomst har egna krav. Den starkaste normala inloggningsmetoden kan undermineras av en svagare reservväg.
Varje aktiv nätverksattack: Protokollparametrar, indatavalidering, ömsesidig bekräftelse och den omgivande autentiserade anslutningen spelar roll. Ersätt inte en driftsättnings föreskrivna TLS-skydd med slagordet ”lösenordet överförs aldrig”.
Metadata eller chattkryptering: Autentisering avgör om en session ska släppas in. Den avgör inte vilka samtalsposter som finns eller vem som har nycklarna för att dekryptera meddelanden.
Hur Livara skiljer inloggning från identitetsåterställning
Livaras säkerhetsöversikt beskriver SRP-autentisering separat från meddelandeprotokollet LVR1. Den dokumenterar också en krypterad identitetssäkerhetskopia i version 7, skyddad av en separat slumpmässig återställningsnyckel på 256 bitar.
Säkerhetskopian förseglas före uppladdning och återställer kryptografisk identitet, inte chatthistorik. Att enbart känna till kontolösenordet återställer inte dessa krypteringsnycklar. Omvänt visar ett påstående om att supporten inte kan återskapa en krypteringshemlighet inte att inga kontohanteringsåtgärder eller lösenordsbytesprocesser kan finnas.
Hotmodellen inkluderar också enhetskompromettering och synliga kommunikationsmetadata. SRP bör inte användas för att beskriva hela tjänsten som ”nollkunskap” om varje aspekt av en användares aktivitet.
En praktisk checklista för bedömning
Som användare bör du välja ett unikt starkt lösenord, skydda enheten, förvara återställningsmaterial på en lämplig separat plats och förstå hur sessioner återkallas. Skriv inte in en hemlighet på en opålitlig webbplats bara för att den påstår sig använda SRP.
Som teknisk granskare bör du begära den exakta protokollprofilen, behandlingen från lösenord till verifierare, indatavalideringen, felhanteringen, registreringsflödet och återställningskonstruktionen. Granska klient och server tillsammans. Inkludera tester av ogiltiga publika värden, återuppspelning och avbrutna sessioner i stället för att enbart lita på ett lyckat inloggningstest.
SRP är ett användbart verktyg för att begränsa lösenordsröjande vid autentisering. Värdet blir tydligare när de verkliga fördelarna beskrivs tillsammans med verifierarstöld, komprometterade ändpunkter och återställningsrisker, i stället för att presenteras som slutet på lösenordssäkerhetens problem.
