SRP voorkomt dat het wachtwoord tijdens het inlogproces wordt verzonden; een gestolen verifier wordt daardoor niet onschadelijk.
Secure Remote Password, of SRP, laat een client en server zich met een wachtwoord authenticeren zonder dat wachtwoord tijdens de normale protocoluitwisseling te verzenden. Dat kan de blootstelling beperken aan een server die het wachtwoord anders bij het inloggen zou ontvangen.
Het verwijdert niet elk wachtwoordgerelateerd geheim van de server. De server bewaart een verifier, en een gestolen verifier kan offline wachtwoordraden mogelijk maken. Dat onderscheid is essentieel bij het beoordelen van beweringen over ‘zero-knowledge-inloggen’.
Wat verandert er ten opzichte van gewoon inloggen met een wachtwoord?
Bij een conventioneel ontwerp verzendt de client het wachtwoord via een geauthenticeerde TLS-verbinding. Een goed ontworpen server vergelijkt een geschikte gezouten wachtwoordhash, voorkomt dat inloggeheimen worden gelogd en past bescherming tegen raadpogingen toe. TLS beschermt de verbinding; een wachtwoordhash beschermt het opgeslagen authenticatiegegeven op een andere manier.
SRP verandert de uitwisseling. Bij registratie legt het systeem een salt en verifiermateriaal vast. Tijdens het inloggen gebruiken beide kanten nieuwe protocolwaarden en hun eigen geheimen om gedeeld sleutelmateriaal vast te stellen en te bevestigen. De client gebruikt het wachtwoord; de server gebruikt zijn verifier. Een eerlijke client verstuurt het wachtwoord zelf niet als inhoud van het inlogverzoek.
De SRP-specificatie in RFC 2945 legt de basis van het protocol uit. Van latere profielen en implementaties moeten de precieze parameters en berichtcontroles worden beoordeeld; een ontwerp ‘SRP’ noemen bewijst niet dat elke implementatiekeuze deugdelijk is.
| Vraag | Conventioneel inloggen met wachtwoord via TLS | Correct geïmplementeerde SRP-uitwisseling |
|---|---|---|
| Ontvangt de toepassingsserver het ingevoerde wachtwoord bij het inloggen? | Gewoonlijk wel | Niet als onderdeel van de protocoluitwisseling |
| Welk gevoelig authenticatiemateriaal wordt opgeslagen? | Meestal een gezouten wachtwoordhash | Salt en een van het wachtwoord afgeleide verifier |
| Kan een gestolen database offline raden mogelijk maken? | Ja, afhankelijk van het opgeslagen materiaal | Ja, gestolen SRP-verifiermateriaal kan raden mogelijk maken |
| Beschermt het tegen een keylogger? | Nee | Nee |
| Versleutelt het automatisch de berichtengeschiedenis? | Nee | Nee |
Waarom een gestolen verifier nog steeds van belang is
Paragraaf 3.3 van RFC 5054 bespreekt gestolen verifiers expliciet. Daarin staat dat een verifier een aanvaller kan laten voordoen als de server en woordenboekaanvallen kan laten uitvoeren om het wachtwoord te achterhalen.
Het belangrijke onderscheid is dat de verifier niet simpelweg een herbruikbaar client-inlogtoken is. Dat maakt hem niet onschadelijk. Een aanvaller kan mogelijke wachtwoorden toetsen aan het gestolen materiaal in plaats van voor elk mogelijk geheim een discreet-logaritmeprobleem op te lossen. Een zwak of hergebruikt wachtwoord blijft een ernstig risico.
Online snelheidslimieten kunnen pogingen tegen een actieve dienst vertragen, maar bepalen niet welke berekeningen op een gestolen database worden uitgevoerd. Databasebescherming, zorgvuldige wachtwoordverwerking en sterke, unieke wachtwoorden blijven relevant.
Waartegen SRP niet beschermt
Een gecompromitteerd eindapparaat: Malware kan het wachtwoord vastleggen voordat het protocol begint of daarna een geauthenticeerde sessie stelen.
Een kwaadaardige inlogpagina: Als de pagina die om het wachtwoord vraagt zelf vijandig is, kan die de ingevoerde tekst elders naartoe sturen. Een webtoepassing heeft nog steeds een betrouwbaar leveringspad nodig.
Alle herstelpaden: Een e-mail-, sms- of ondersteuningsproces dat accounttoegang verleent, heeft eigen vereisten. De sterkste normale inlogmethode kan worden ondermijnd door een zwakkere terugvaloptie.
Elke actieve netwerkaanval: Protocolparameters, invoervalidatie, wederzijdse bevestiging en de omringende geauthenticeerde verbinding zijn belangrijk. Vervang de voorgeschreven TLS-bescherming van een implementatie niet door de slogan ‘het wachtwoord wordt nooit verzonden’.
Metadata of chatversleuteling: Authenticatie beantwoordt de vraag of een sessie moet worden toegelaten. Zij bepaalt niet welke gespreksgegevens bestaan of wie de sleutels voor het ontsleutelen van berichten bezit.
Hoe Livara inloggen scheidt van identiteitsherstel
Livara’s beveiligingsoverzicht beschrijft SRP-authenticatie afzonderlijk van het LVR1-berichtenprotocol. Het documenteert ook een versleutelde identiteitsback-up van versie 7, beschermd door een afzonderlijke willekeurige herstelsleutel van 256 bits.
De back-up wordt vóór het uploaden cryptografisch verzegeld en herstelt de cryptografische identiteit, niet de chatgeschiedenis. Alleen het accountwachtwoord kennen herstelt die versleutelingssleutels niet. Omgekeerd bewijst de uitspraak dat ondersteuning een versleutelingsgeheim niet kan reconstrueren niet dat er geen accountbeheerhandelingen of wachtwoordwijzigingsproces kunnen bestaan.
Het dreigingsmodel omvat ook gecompromitteerde apparaten en zichtbare communicatiemetadata. SRP mag niet worden gebruikt om de volledige dienst als ‘zero knowledge’ over elk aspect van de activiteit van een gebruiker te bestempelen.
Een praktische beoordelingschecklist
Kies als gebruiker een uniek, sterk wachtwoord, bescherm het apparaat, bewaar herstelmateriaal op een geschikte afzonderlijke plek en begrijp hoe sessies worden ingetrokken. Voer geen geheim in op een onbetrouwbare site alleen omdat die beweert SRP te gebruiken.
Vraag als technisch beoordelaar naar het precieze protocolprofiel, de verwerking van wachtwoord naar verifier, invoervalidatie, foutafhandeling, registratieproces en resetontwerp. Beoordeel client en server samen. Neem tests op voor ongeldige openbare waarden, herhalingsaanvallen en onderbroken sessies, in plaats van uitsluitend op een geslaagde inlogtest te vertrouwen.
SRP is een nuttig hulpmiddel om het prijsgeven van wachtwoorden tijdens authenticatie te beperken. De waarde ervan is duidelijker wanneer de werkelijke voordelen naast verifierdiefstal, gecompromitteerde eindapparaten en herstelrisico’s worden beschreven, in plaats van SRP als het einde van wachtwoordbeveiligingsproblemen te presenteren.
