SRP - Logindaten in Datenbank speichern

[maddin4u]

Hallo

Ich versuche mit Hilfe des Secure Remote Protocol von einen Hagen Sicheren Datenaustausch zwischen Client und Server zu realisieren. Dies klappt auch soweit.

Nun möchte ich allerdings alle Login-Daten (z. B. Username, Passwort) in einer MySQL Datenbank speichern. Das Problem ist das ich nicht genau weiss wie ich das realisieren soll.

Wie ich jetzt rausgelesen habe ist es möglich sein eigenes Datenbank-Interface (ISRPDatabase) zu erstellen. Meine Versuche sind allerdings fehlgeschlagen. Es wäre klasse wenn mir jemand einen Anhaltspunkt geben kann, wie ich soll ein Interface implementiere, um die Daten in einer eigenen Datenbank zu speichern. Oder gibt es noch eine andere Möglichkeit?

Vielen Dank
maddin

[negaH]

Hi,

im Attachment mal meine Originalsource für die beiden "Datenbanken" die die DLL von Hause aus unterstützt. Du musst im Grunde nur die Methoden

Delphi-Quellcode:

    function DoLookup(const Ident: WideString): WideString; override;
    function DoStore(const Ident, Data: WideString; IsEphemeral: Boolean): WideString; override;
    procedure DoDelete(const Ident: WideString); override;

anders implementieren. Zb. ein TDataModule erzuegen in TSRPDatabaseINI.Create das deine SQL anspricht. In obigen Methoden dann deine Datensätze suchen,löschen oder speichern.

Bedenke aber eines, meine modifizierte Version des SRP6a hat zu Folge das bei jedem erfolgreichen Login

- einmal .DoLookup() aufgerufen wird
- einmal .DoStore() aufgerufen wird.

Im Orginal SRP sind die registrieren Nutzerdaten, einmal registriert, für immer unveränderlich. Man liest dann nur noch die Datenbank.
Bei meinem modifiziertem SRP kommt nun noch eine Speicheroperation bei jedem erfolgreichem Login hinzu. Das liegt daran weil defakto sich der Passwortverifier und somit gegebenenfalls auch auf Benutzerwunsch hin das benutzte Passwort, ändert.
Dh. der Nachteil der zusätzlichen Speicherung wird zum Vorteil weil der Benutzer ohne das es der Server mitbekommt zu jeder Zeit sein Passwort ändern kann. Natürlich auf mathem. beweisebar sichere Art&Weise.

Der einzigste kritische Moment ist die Registration eines neuen Users. Du soltest ein Boolean -> Registered und einen Datumswert in deine DB aufnehmen. IsEmpheral = True bei .DoStore() bedeutet das der User erstmal nur einen Registrations-Account bekommen hat. Nun sollte innerhalb einer limitierten Zeitspanne der Benutzer sich regulär einloggen und sein richtiges Passwort ändern. IsEmpheral sollte dann FALSE werden (nach erfolgreichem Login). Solange dies nicht der Fall ist MUSST du aus Sicherheitsgründen die Zugriffsrechte des Benutzers stark einschränken. Denn der Registrationsprozess ist der einzigste Zeitpunkt bei der eine MITMA->Man in the middle Attack möglich wäre. Die zeitspanne zwischen Ausgabe eines Registrationskeys und 1. erfolgreicher Anmeldung + Änderung des Passwortes durch den User sollte sehr kurz sein. Und solange IsEmpheral auf TRUE ist darf über diesen Acccount kein Zugriff auf Rechnerresourcen erlaubt sein.

Ansonsten eine sehr gute Entscheidung.

Gruß Hagen

[negaH]

nochwas

Zitat:

Nun möchte ich allerdings alle Login-Daten (z. B. Username, Passwort) in einer MySQL Datenbank speichern

Das Passwort und der lesbare Benutzername werden NIEMALS in der Datenbank auf dem Server gespeichert. Genauergesagt:

-> Benutzername nur als gehashte Version
-> Passwort des Benutzers verlässt nicht den Computer des Clients

Nur der Benutzer und der Client Rechner kennen das wahre Passwort, es wird nicht zum Server übertragen oder ähnliches. SRP ist ein asymmetrisches zero knownledge Verfahren, da werden keine extrahierbaren Informationen zum Passwort versendet. Da es zusätzlich ein Mehrfaktorprotokoll ist sind MITMA Angriffe ausgeschlossen, sobald es zu einer gültigen Erstregistration kam.

Gruß Hagen

[maddin4u]

Vielen Dank für die Antwort und den Code.

Wenn Ich das jetzt richtig verstanden habe, ist es aber Ok wenn ich den Usernamen und das Passwort als Hash in meine Datenbank speicher?! Denn wenn die Logindaten nur auf dem Client gespeichert wären, müsste ein User sich ja jedesmal neuregistrieren wenn der Client neugestartet wird?!

Also: Speicher ich Username und Passwort als Hash in meiner MySQL Datenbank kann ich jederzeit drauf zugreifen, auch wenn der Client neugestartet wird etc.?

Thx!
maddin

[negaH]

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

[negaH]

In deiner Datenbank sollten folgende Felder enthalten sein

1.) Ident: String -> enthält den Hash über den realen Benutzernamen und kann als Index dienen. Das hat den Vorteil das dieses Feld immer die gleiche Länge haben wird, logisch der Hash ist ja bei jedem Benutzernemen immer gleich lang
2.) Data: String -> enthält in MIME64 formatiert alle Daten die SRP benötigt. Also Zufalls-Verifier zum Passwort, öffentliche Domain Paramater sprich die Primzahl usw., dann den aktuellen Login Counter usw. Dies wäre bildlich gesehen vergleichbar zu deinem Hash übers Passwort.

Das sind die Minimalforderungen.

3.) IsEmpheral: Boolean; bezeichnect einen eingeschränkten Account, also wenn in Data nur ein mit .RegisterUser() erzeugter Key drinnen ist
4.) TimeOutDate: TDateTime; das Datum bis wann ein mit IsEmpheraml=TRUE erzeugter Datensatz gültig ist, also bis zu diesem Datum muß sich der Client mindestens einmal eingeloggt haben

Das waren die Felder die man benötigt um Zugriffskontrolle sicherer zu machen.

5.) EMail
6.) lesbarer Username

Das sind Felder die man in vielen Fällen nicht vermeiden kann, einfach weil es organisatorisch nicht anders geht. Will man "perfekte" Sicherheit so sollte man auf diese Felder verzichten oder sie zumindetens verschlüsselt speichern.

Gruß Hagen

[maddin4u]

Hallo.

Tausend Dank für die ausführliche Anleitung. Das ganze hat mir bis jetzt sehr geholfen.

Vermutlich werde ich mich später nochmal zu Wort melden, falls etwas noch unklar ist. Aber erstmal werde ich alleine etwas rumwerkeln ;o)

Mit freundlichen Grüßen
maddin4u

[maddin4u]

Zitat:

Vermutlich werde ich mich später nochmal zu Wort melden, falls etwas noch unklar ist

Genau das ist jetzt der Fall.

Aus organisatorischen Gründen müsste ich den Benutzernamen auch in der Datenbank speichern, da der Benutzer nach der Registration zu einer Gruppe zugeordnet werden soll. Die Zuordnung fällt etwas schwer wenn in der dafür vorgesehenen Oberfläche nicht der Benutzername angezeigt werden kann, da er ja nirgends gespeichert ist.

Auch wenn das ganze dann nicht mehr der SRP-Philosophie entspricht, wie in den oberen Beiträgen erklärt, wäre es aber notwendig.

Wie würde es mir also gelingen, trotz der abnehmenden Sicherheit, den Benutzernamen mitzuspeichern?

Gruß
Martin

[negaH]

Tja, erstmal garnicht da der Benutzername im laufenden Protokoll nicht vorhanden ist, sondern nur ein Hashdigest davon. Allerdings wird bei der Registration eines neuen Benutzers dieser Benutzername auch auf Serverseite benötigt, also wenn dann exakt in diesem Moment speichern.
Das Problem ist aber das ich im Grunde die SRP.DLL verändern müsste, inklusive dessen Interfaces damit das funktioniert.

Im original SRP wird der Benutezrname immer lesbar übermittelt und auch gespeichert. Das wollte ich aber gerade verhindern um Zuordnungen von Benutzern in geklauten Server Datenbanken zu vermeiden.

Gruß Hagen