Nein das hast du falsch verstanden
Das Passwort wird auch nicht als gehashte Version in der
DB gespeichert. Der Server KENNT es garnicht und darf es auch nicht kennen, selbst nicht den Hash eines Passwortes.
Normalerweise ist das Prozessing so:
1.) Client sendet seinen UserNamen
2.) SRPServer.RegisterClient erzeugt einen vorläufigen zufälligen Registrationskey und trägt in SRPDatabase.Store(Ident, Data, TRUE) diesen ein, vorläufiger Account
3.) Server sendet zb. per EMail diesen Registrationskey an den User
4.) User loggt sich das erste mal ein, benutzt Registrationskey als 1. Passwort und als 2. Passwort sein privates. Damit loggt sich User ein und übermittelt quasis die Verfifikationsdaten zum neuen Passwort, NICHT das Passwort ansich ! Der User ändert also seinen Account vom Registrationspasswort mit seinem eigentlich richtigen Passwort
5.) Server überprüft zum User aus der SRPDatabase.Lookup() den Verifier zum Registrationkey. Wenn ok, wird mit SRPDatabase.Store() der neue Verifier zum neuen Passwort gespeichert, dieser Prozess wiederholt sich bei jedem Login und der User hat somit die Möglichkeit zu jeder Zeit das Passwort zu ändern
Bei all diesen Operationen werden nur sogenannte Verifiers übermittelt. Diese sind mathematisch abhängig von den Passwörtern können aber auf Grund der benutzen Mathematik nicht zu den basierenden Paswörtern zurückgerechnet werden. Auch ein Lauscher hat auf Grund des Mehrstufenprotokolles nicht die Möglichkeit sich dazwischen zu schalten. Das liegt auch daran weil wir eine gegenseitige Authentifizierung druchführen. Dh. der Client authentifiziert sich beim Server und der Server authentifiziert sich beim Clienten.
Der Lauscher kann auch keine Reply-Attacke durchführen, dh. eine zeitlang mehrere Logins belauschen, Daten sammeln und daraus irgendwelche Informationen offline, berechnen. Auch das verhindert SRP mathematisch beweisbar. Auch eine Vertauschung im Mehrstufenprotokoll ist nicht möglich. SRP stellt damit nach meiner Meinung die modernste Technologie in der "Passwort basierten Authentifikation" dar.
Beide, Client & Server, führen ein Zero Knownledge Protokoll durch und können nach erfolgreicher Aktion sicher sein das am anderen Ende auch wirklich derjenige sitzt den man erwartet. Als Nebeneffekt vereinbaren beide noch ein gemeinsammes "Shared Secret", ein gemeinsammes Geheimnis, ein Zufallspasswort. Dh. SRP führt auch noch gleich einen sogenannten "Schlüsselaustausch" durch. Das Wort ist leider so eingebürgert und suggeriert einem ein komplett falsches Bild. In Wahrheit werden keinen Schlüssel "ausgetauscht" da dies suggeriert das man Schlüssel versendet, überträgt übers Internet. Dies ist falsch. Man erzeugt in parallel auf beiden Seiten (Client & Server) ein gemeinsammes Geheimnis OHNE das relevante und zurückrechenbaren Informationen übers Internet ausgetauscht werden.
SRP macht also folgende Sachen:
1.) Authentifikation Client beim Server
2.) Authentifikation Server beim Clienten
3.) Vereinbarung eines zufälligen Session-Passwortes für die spätere Verschlüsselte Übertragung von Daten -> Server/Client.Encrypt()
Counter-SRP6 von mir macht nun folgendes zusätzlich zum Orginal
4.) ständige Veränderung, zufallsabhängig, des Passwortverifiers zum Clienten
5.) Client kann jederzeit durch ein Login sein Passwort ändern OHNE das dies auf Serverseite bemerkbar ist
6.) alle Daten in der Server Datenbank sind anonymisiert
7.) es gibt einen Login-Counter den man auf verschiedene Weise benutzen kann. Entweder umd einen Account in der Lebenszeit zu beschränken, zb. wenn er runterzählen würde. Oder als zusätzliches Sicherheitsmerkmal auf Clientseite. Denn zu jedem Zeitpunkt ist ein Diebstahl des realen Passwortes auf Clientseite möglich, per Trojaner zb. Wird nun ein solch gestohlenes Passwort illegalerweise benutzt so kann sich der Hacker sehr wohl Zugriff verschaffen, logisch. Das ist aber bei ALLEN Verfahren so ! Wichtig ist aber das nun der Account-Counter sich jedesmal inkrementiert. Ein Client der sich diesen Counter merkt kann also erkennen das der Counter sich im Vergleich zum letzten Login um mehr als +1 verändert hat. Sollte dies der Fall sein so fanden in der Zwichenzeit also noch andere gültige Logins statt. In diesem Moment sollte der Client entweder den Account sperren oder einfach ein neues Passwort eingeben. Das sind beides identische Operationen. Dh. der Client loggt sich mit seinem alten/geknackten Passwort ein und übermittelt gleichzeitg ein neues Passwort. Damit wird das alte geklaute Passwort ungültig und der Hacker muß erneut den Clientrechner hijacken um an das neue Passwort zu kommen. Ergo: auf Grund dieser Möglichkeiten halte ich meinen Counter-SRP für sicherer als den Original SRP.
Ich empfehle also NICHT den Usernamen und irgendwelche anderen Daten lesbar in der Server Datenbank zu speichern. Ich weis das dies manchmal nicht möglich ist. Aber man sollte den Fall berücksichtigen das
1.) der Server selber der Feind ist
2.) der Server hijacked wurde
In beiden Fällen sollten wir verhindern das der hacker/Server mit Hilfe der Datenbank eine Offline Brute Force Attacke auf den Clienten und sein Passwort durchführen kann. Um dies zu können muss der Hacker/Hijacker/Server die Informationen haben einen User zu einem Datensatz zuordnen zu können. Würde man in der
DB den Usernamen + EMail Addresse speichern so kann der Hacker dies bewerkstelligen. Es ist also wichtig das die Clienten nach Möglichkeit vollkommen anonym in der
DB gespeichert werden.
Ergo: das in meinem SRP benutze Protokoll stellt auch sicher das man mit einer gestohlenen Passwortdatenbank den Clienten eben nicht angreifen kann.
Wichtig ist dies weil wir Menschen in der Wahl unserer Passwörter eben sehr unkreativ sind. Wir benutzen zu kurze Passwörter die einer Offline Brute Force Attacke zb. per Rainbowtables nicht standhalten (in Sekunden knackbar sind) und zweitens weil wir für alle unsere Accounts häufig identische oder ähnliche Passwörter benutzen. Wenn aber der Hacker nicht den Datensatz zum Clienten ermitteln kann dann kann er auch nicht einen Clienten gezielt angreifen und somit eventuell auf dessen Online Banking Passwort kommen.
Du solltest also im
GUI deiner Client Software folgenden Passwort/LOgin Dialog reinbauen
1.) Passwort Edit Control für das aktuell gültige Passwort
2.) ein Label das SRPCLient.Counter als Zahl anzeigt
3.) eine zuschaltbare Möglichkeit für ein zweites Passwort-Edit-Control zur Eigabe eines neuen Passwortes. Dies musst du sowieso da beim Registrationsprocess = 1. Anmeldung der User ja nur ein vorläufiges Regstrationspasswort im 1. Edit eingeben muß. Im 2. Edit muß der Cliet immer sein neues und real zu benutztendes Passwort eingeben. Dieses wird dann in den nächsten Logins autom. gültig.
Gruß Hagen