SRP: Secure Remote Password Protocol

Das Protokoll Secure Remote Password (SRP) wurde von Tom Wu an der Stanford University entwickelt und im Jahr 2000 als RFC 2945 veröffentlicht; später wurde die verbesserte Version SRP-6a definiert. SRP ermöglicht eine gegenseitige Authentifizierung auf Grundlage eines gemeinsamen Passworts, ohne das Passwort selbst jemals zu übertragen – auch nicht in verschlüsselter Form.

Bei der SRP-Registrierung berechnet der Client einen Passwort-Verifier v = g^x mod N, wobei x = H(salt || password) und N eine große sichere Primzahl ist. Der Server speichert ausschließlich das Salt und den Verifier v. Selbst wenn die Serverdatenbank kompromittiert wird, gibt der gespeicherte Verifier das Passwort nicht direkt preis.

Während der SRP-Anmeldung führen Client und Server einen Diffie-Hellman-ähnlichen Austausch durch, bei dem ein gemeinsamer Sitzungsschlüssel erzeugt wird. Die Berechnung auf beiden Seiten bezieht den aus dem Passwort abgeleiteten Wert ein. Daher kann der resultierende Sitzungsschlüssel nur von jemandem korrekt berechnet werden, der jeweils das Passwort beziehungsweise den Verifier kennt.

SRP bietet gegenseitige Authentifizierung: Der Client weist nach, dass er das Passwort kennt, und der Server weist nach, dass er den legitimen Verifier besitzt. Dadurch werden Phishing-Angriffe verhindert, bei denen ein gefälschter Server versuchen könnte, Passwortinformationen zu sammeln, denn ein gefälschter Server kann den SRP-Austausch ohne den echten Verifier nicht korrekt abschließen.

Der Verifier wird als v = g^x mod N berechnet, wobei x = H(salt || password), g ein Generator und N eine sichere Primzahl mit mindestens 2048 Bit ist. Aufgrund des diskreten Logarithmusproblems ist es praktisch nicht möglich, x aus v zurückzugewinnen. Das Passwort kann nur durch den erfolgreichen Abschluss des vollständigen SRP-Austauschs überprüft werden.

SRP-6a behebt Schwächen der ursprünglichen Entwürfe SRP-3 und SRP-6, indem es den Multiplikatorparameter k = H(N, g) einführt und die Reihenfolge der Berechnungen auf Client- und Serverseite verändert. Diese Änderungen verhindern bestimmte Zwei-für-eins-Rat angriffe und stellen sicher, dass der Beitrag des Servers früh im Protokoll gebunden wird.

SRP wurde in der Praxis umfangreich eingesetzt. Apple verwendet SRP bei der Synchronisierung des iCloud Keychain, damit Geräte Schlüsselbunddaten abrufen können, ohne das Kontopasswort an die Server von Apple zu verraten. 1Password hat SRP in seinem Authentifizierungsmodell verwendet, um die Offenlegung von Zugangsdaten auf dem Server zu verhindern.

Da SRP einen Sitzungsschlüssel erzeugt, der sowohl das Passwort als auch den Verifier des Servers bindet, kann ein Phishing-Server den SRP-Handshake nicht korrekt abschließen. Ein Benutzer, der sich über SRP mit einer Phishing-Website verbindet, kann sich nicht authentifizieren. Dadurch besitzt SRP eine integrierte Anti-Phishing-Eigenschaft, die bei der herkömmlichen Übertragung von Passwörtern fehlt.

SRP ist rechenintensiv, da Modularexponentiation mit großen Ganzzahlen (mindestens 2048 Bit) erforderlich ist. Das Protokoll ist schwierig korrekt zu implementieren; zahlreiche subtile Probleme bei der Parameterprüfung haben zu Sicherheitslücken in Implementierungen geführt. Außerdem benötigt das Protokoll einen sicheren Kanal (TLS), um passives Belauschen des Austauschs selbst zu verhindern.

RFC 5054 definiert TLS-SRP-Verschlüsselungssammlungen, die die gegenseitige SRP-Authentifizierung direkt in den TLS-Handshake integrieren. Dadurch werden keine Serverzertifikate benötigt, während weiterhin eine verschlüsselte gegenseitige Authentifizierung gewährleistet ist. TLS-SRP hat sich in der Praxis jedoch nur begrenzt durchgesetzt, da FIDO2 und OPAQUE als modernere Alternativen aufgekommen sind.

Obwohl SRP bahnbrechend war, bieten moderne Alternativen wie OPAQUE stärkere Sicherheitsgarantien (Schutz vor Vorberechnung), und FIDO2/Passkeys machen Passwörter vollständig überflüssig. Für neue Systeme werden OPAQUE oder FIDO2 bevorzugt. SRP bleibt jedoch eine geeignete Wahl für Systeme, die eine passwortbasierte gegenseitige Authentifizierung ohne Anfälligkeit für Phishing benötigen.

Was speichert der Server bei SRP anstelle des Passworts des Benutzers?

SRP speichert einen Passwort-Verifier, nicht das Passwort, erzeugt durch einen DH-ähnlichen Austausch einen gemeinsamen Sitzungsschlüssel und bietet eine gegen Phishing resistente gegenseitige Authentifizierung. SRP-6a verbessert das ursprüngliche Protokoll durch Schutz vor Rateangriffen. Apples iCloud Keychain und 1Password verwenden SRP in Produktivsystemen. OPAQUE und FIDO2 sind moderne Nachfolger für neue Systeme.