SRP vermeidet das Senden des Passworts beim Anmeldeaustausch; ein gestohlener Verifikator wird dadurch nicht harmlos.
Secure Remote Password, kurz SRP, ermöglicht es Client und Server, sich mit einem Passwort zu authentifizieren, ohne dieses im normalen Protokollaustausch zu senden. Dadurch kann die Offenlegung gegenüber einem Server verringert werden, der das Passwort ansonsten bei der Anmeldung erhalten würde.
SRP entfernt nicht jedes passwortbezogene Geheimnis vom Server. Der Server speichert einen Verifikator, und ein gestohlener Verifikator kann Offline-Passwort-Raten ermöglichen. Diese Unterscheidung ist bei der Bewertung von Aussagen über eine „Zero-Knowledge-Anmeldung“ wesentlich.
Was ändert sich gegenüber einer herkömmlichen Passwortanmeldung?
Bei einem herkömmlichen Design sendet der Client das Passwort über eine authentifizierte TLS-Verbindung. Ein gut entworfener Server vergleicht einen geeigneten gesalzenen Passwort-Hash, vermeidet das Protokollieren von Zugangsdaten und schützt vor Rateversuchen. TLS schützt die Verbindung; ein Passwort-Hash schützt die gespeicherten Zugangsdaten auf andere Weise.
SRP verändert den Austausch. Bei der Registrierung legt das System Salt und Verifikatormaterial an. Bei der Anmeldung verwenden beide Seiten frische Protokollwerte und ihre jeweiligen Geheimnisse, um gemeinsames Schlüsselmaterial zu vereinbaren und zu bestätigen. Der Client verwendet das Passwort, der Server seinen Verifikator. Ein ehrlicher Client übermittelt das Passwort selbst nicht als Anmeldenutzlast.
Die SRP-Spezifikation in RFC 2945 erläutert die Grundlagen des Protokolls. Bei späteren Profilen und Implementierungen müssen die genauen Parameter und Nachrichtenprüfungen untersucht werden; die Bezeichnung „SRP“ belegt nicht, dass jede Implementierungsentscheidung solide ist.
| Frage | Herkömmliche Passwortanmeldung über TLS | Korrekt implementierter SRP-Austausch |
|---|---|---|
| Erhält der Anwendungsserver das eingegebene Passwort bei der Anmeldung? | Normalerweise ja | Nicht als Teil des Protokollaustauschs |
| Welche sensiblen Authentifizierungsdaten werden gespeichert? | Typischerweise ein gesalzener Passwort-Hash | Salt und ein aus dem Passwort abgeleiteter Verifikator |
| Kann eine gestohlene Datenbank Offline-Raten ermöglichen? | Ja, abhängig vom gespeicherten Material | Ja, gestohlenes SRP-Verifikatormaterial kann Rateversuche ermöglichen |
| Schützt das Verfahren vor einem Keylogger? | Nein | Nein |
| Verschlüsselt es den Nachrichtenverlauf automatisch? | Nein | Nein |
Warum ein gestohlener Verifikator weiterhin wichtig ist
Abschnitt 3.3 von RFC 5054 behandelt ausdrücklich gestohlene Verifikatoren. Er erklärt, dass ein Verifikator einem Angreifer ermöglichen kann, sich als Server auszugeben und Wörterbuchangriffe durchzuführen, um das Passwort zu ermitteln.
Wichtig ist die Unterscheidung, dass der Verifikator nicht einfach ein wiederverwendbares Anmeldetoken für den Client ist. Harmlos wird er dadurch nicht. Ein Angreifer kann mögliche Passwörter gegen das gestohlene Material prüfen, statt für jedes mögliche Geheimnis ein diskretes Logarithmusproblem zu lösen. Ein schwaches oder wiederverwendetes Passwort bleibt ein ernstes Risiko.
Online-Ratenbegrenzungen können Versuche gegen einen laufenden Dienst verlangsamen, kontrollieren aber keine Berechnungen auf einer gestohlenen Datenbank. Datenbankschutz, sorgfältige Passwortverarbeitung und starke, einzigartige Passwörter bleiben relevant.
Wovor SRP nicht schützt
Ein kompromittiertes Endgerät: Schadsoftware kann das Passwort vor Beginn des Protokolls erfassen oder danach eine authentifizierte Sitzung stehlen.
Eine bösartige Anmeldeseite: Ist die Seite, die nach dem Passwort fragt, selbst feindlich, kann sie den eingegebenen Text anderswohin senden. Eine Webanwendung benötigt weiterhin einen vertrauenswürdigen Auslieferungspfad.
Alle Wiederherstellungswege: Ein E-Mail-, SMS- oder Supportablauf, der Kontozugriff gewährt, hat eigene Anforderungen. Die stärkste reguläre Anmeldemethode kann durch einen schwächeren Rückfallweg untergraben werden.
Jeder aktive Netzwerkangriff: Protokollparameter, Eingabevalidierung, gegenseitige Bestätigung und die umgebende authentifizierte Verbindung sind wichtig. Ersetzen Sie die vorgeschriebenen TLS-Schutzmaßnahmen einer Bereitstellung nicht durch den Slogan „das Passwort wird nie übertragen“.
Metadaten oder Chatverschlüsselung: Authentifizierung beantwortet, ob eine Sitzung zugelassen werden soll. Sie bestimmt nicht, welche Gesprächsaufzeichnungen existieren oder wer die Schlüssel zur Nachrichtenentschlüsselung besitzt.
Wie Livara Anmeldung und Identitätswiederherstellung trennt
Livaras Sicherheitsübersicht beschreibt die SRP-Authentifizierung getrennt vom LVR1-Nachrichtenprotokoll. Sie dokumentiert außerdem ein verschlüsseltes Identitätsbackup der Version 7, das durch einen separaten zufälligen 256-Bit-Wiederherstellungsschlüssel geschützt wird.
Das Backup wird vor dem Hochladen verschlüsselt versiegelt und stellt die kryptografische Identität wieder her, nicht den Chatverlauf. Die Kenntnis eines Kontopassworts allein stellt diese Verschlüsselungsschlüssel nicht wieder her. Umgekehrt belegt die Aussage, dass der Support ein Verschlüsselungsgeheimnis nicht rekonstruieren kann, nicht, dass keinerlei Kontoverwaltung oder Passwortänderung möglich sein kann.
Das Bedrohungsmodell berücksichtigt auch kompromittierte Geräte und sichtbare Kommunikationsmetadaten. SRP sollte nicht dazu dienen, dem gesamten Dienst „Zero Knowledge“ über jeden Aspekt der Nutzeraktivität zuzuschreiben.
Eine praktische Prüfliste
Wählen Sie als Nutzer ein einzigartiges, starkes Passwort, schützen Sie das Gerät, bewahren Sie Wiederherstellungsmaterial an einem geeigneten separaten Ort auf und verstehen Sie, wie Sitzungen widerrufen werden. Geben Sie kein Geheimnis auf einer nicht vertrauenswürdigen Website ein, nur weil diese behauptet, SRP zu verwenden.
Fordern Sie als technischer Prüfer das genaue Protokollprofil, die Verarbeitung vom Passwort zum Verifikator, Eingabevalidierung, Fehlerbehandlung, Registrierungsablauf und Rücksetzdesign an. Prüfen Sie Client und Server gemeinsam. Beziehen Sie Tests für ungültige öffentliche Werte, Replay und unterbrochene Sitzungen ein, statt sich nur auf eine erfolgreiche Testanmeldung zu verlassen.
SRP ist ein nützliches Werkzeug, um die Offenlegung von Passwörtern bei der Authentifizierung zu begrenzen. Sein Nutzen wird klarer, wenn seine tatsächlichen Vorteile gemeinsam mit Verifikatordiebstahl, kompromittierten Endgeräten und Wiederherstellungsrisiken beschrieben werden, statt es als Ende aller Passwortsicherheitsprobleme darzustellen.
