SRP verstuurt het wachtwoord niet binnen het protocol; dat is niet hetzelfde als het afschaffen van wachtwoorden, immuniteit tegen phishing of een ongevaarlijke verifier.
Passkeys en SRP zijn twee verschillende manieren van authenticatie. Een passkey gebruikt een sleutelpaar en kan de noodzaak van een wachtwoord wegnemen. SRP is nog steeds gebaseerd op een wachtwoord, maar verstuurt bij een correcte uitvoering van het protocol het wachtwoord zelf niet naar de server om te bewijzen dat de gebruiker het kent.
‘Inloggen zonder een wachtwoord te versturen’ is dus niet hetzelfde als ‘inloggen zonder een wachtwoord te hebben’. De keuze tussen deze methoden moet steunen op phishingrisico, beheer van inloggegevens, herstel en implementatiekwaliteit, niet op het algemene etiket ‘zero knowledge’.
Wat verandert een passkey?
Bij authenticatie met passkeys bewaart de dienst de publieke sleutel en bevestigt de gebruiker de aanmelding door de privésleutel te beheersen. De koppeling van het inlogmiddel aan de betreffende dienst en oorsprong is een belangrijk onderdeel van de phishingweerstand. FIDO’s uitleg over passkeys.
Niet alle passkeys worden noodzakelijk in de cloud gesynchroniseerd. Sommige zijn gebonden aan één apparaat of beveiligingssleutel; andere worden via de aanbieder van inloggegevens tussen apparaten overgebracht. Het herstelmodel en de bescherming van de synchronisatie moeten voor die specifieke aanbieder worden onderzocht. Alleen uit ‘cloudsynchronisatie’ kan niet worden afgeleid dat het bedrijf sleutels in leesbare vorm bewaart.
Ook de sessiebeveiliging na het inloggen is een aparte kwestie. Een passkey neutraliseert niet automatisch malware op het apparaat of de diefstal van een geldige sessie.
Wat geeft SRP aan de server?
SRP behoort tot de familie van met een wachtwoord geauthenticeerde sleuteluitwisselingen. In plaats van het wachtwoord zelf bewaart de server gegevens zoals een salt en een verifier. Door protocolberichten uit te wisselen controleren beide partijen kennis van het geheim en de gedeelde sleutel.
Maar een verifier is geen ongevaarlijk gegeven. Paragraaf 3.3 van RFC 5054 stelt expliciet dat een aanvaller die de verifier bemachtigt een woordenboekaanval kan uitvoeren om het wachtwoord te raden. De bewering dat ‘diefstal van de database geen enkele mogelijkheid tot offline raden biedt’ is dus onjuist.
Een sterk wachtwoord, serverbeveiliging, passende parameters, invoervalidatie en controle op inlogpogingen blijven nodig. SRP garandeert evenmin dat de pagina waarop je het wachtwoord typt veilig is; kwaadaardige code kan het onderscheppen voordat het protocol wordt uitgevoerd.
Een eerlijke vergelijking
| Vraag | Passkey | SRP |
|---|---|---|
| Onthoudt de gebruiker een wachtwoord voor de dienst? | Meestal niet; controle over het inlogmiddel is nodig | Ja, de methode berust op kennis van het wachtwoord |
| Wat bewaart de dienst voor het inloggen? | De publieke sleutel en bijbehorende informatie | De verifier en bijbehorende parameters |
| Hoe ontstaat phishingweerstand? | Koppeling van het inlogmiddel aan de dienst/oorsprong in het FIDO-ontwerp | Het niet versturen van het wachtwoord binnen het protocol is niet genoeg om een vervalst invoerscherm veilig te maken |
| Is de cloud verplicht? | Nee; er bestaan ook apparaatgebonden opties | Het protocol vereist niet inherent een externe identiteitsaanbieder, maar wel een authenticatiedienst |
| Hoe werkt herstel? | Afhankelijk van het soort inlogmiddel en de aanbieder | Bepaald door het account- en productbeleid, niet door de naam SRP |
Deze tabel levert geen absolute rangschikking voor alle implementaties op. Een zwakke herstelprocedure kan de voordelen van een sterke inlogmethode ondermijnen.
Wat is het verband tussen accountlogin en chatsleutels?
Authenticatie vertelt de dienst wie mag handelen. Berichtversleutelingssleutels bepalen wie de inhoud kan ontsleutelen. Een product kan deze twee met elkaar verbinden, maar die relatie moet gedocumenteerd zijn.
In Livara’s beveiligingsdocumentatie wordt SRP beschreven voor het inloggen en wordt het v7-herstelpakket voor de versleutelde identiteit afzonderlijk behandeld. Dat pakket herstelt de identiteit, niet de chatgeschiedenis. Daarom betekent ‘het inlogwachtwoord klopt’ niet ‘alle sleutels en oude berichten zijn terug’.
Dit artikel is een conceptuele vergelijking, geen praktijktest van alle inlogmethoden van Livara of bevestiging dat het product een RFC exact implementeert.
Welke vragen moet je stellen bij de keuze?
- Als het apparaat verloren raakt, wat is dan de alternatieve inlogroute en wie beheert die?
- Is de herstelmethode zwakker dan de primaire inlogmethode?
- Hoe worden onbekende sessies bekeken en ingetrokken?
- Verandert een andere inlogmethode de berichtsleutels of gekoppelde apparaten?
- Welk account en welke onafhankelijke bescherming zijn nodig om inloggegevens te synchroniseren?
Kortom: Noem passkeys niet inherent ‘onveilig omdat ze in de cloud staan’ en SRP niet ‘immuun voor inbreuken omdat het zero knowledge is’. De grenzen van elke methode en het herstelbeleid van het product vormen de basis van een betrouwbare vergelijking.
