Benutzerdaten einer Website - weg von MD5

**himitsu**

und wenn man dann noch Sakura's Salts mit einbezieht, dann kommt man schon auf 'ne nette Variante, die schön viele mögliche unterschiedliche Zustände zuläßt

PasswortHash = md5(vary(variablerSalt . festerSalt . Passwort));

festerSalt ist in 'ner PHP-Datei definiert (zum Ausgleich, der "Unsicherheit" der variablen Salts ... da hier wohl schwerer ranzukommen sein sollte)

variablerSalt wird beim festlegen/ändern des Passwortes für jeden Benutzer neu festgelegt und, weils einfach ist, mit in der DB gespeichert
(damit bei gleichen Paswörtern unterschiedliche Hashs rauskommen)

und bei zu häufiger falscher Passwort eingabe sollte eh etwas geblockt/ausgebremst werden.

**negaH**

also wenn dann so

PasswortHash = variablerSalt || md5(vary(variablerSalt || festerSalt || Passwort));

Immer erst die Zufallsdaten und daran die festen Daten hashen. Eine Hashfunktion hat einen Lawineneffekt. Je veränderlicher die ersten Bits der Daten sind desto mehr Einfluß haben sie auf den internen Status der nachfolgenden Bits die man hasht.

Aber grundsätzlich ist ein solches Loginsystem unsicher. Ein gutes Loginsystem ist in der Lage eine Authentifikation in mehreren Stufen (minimal 3) durchzuführen. Dabei authentifiziert es den Client beim Server, den Server beim Client und die kompletten vorherig getätigten Protokollschritte. Dabei darf das reale Benutzerpasswort nirmals den Clientrechner verlassen ! Hasht man auf einem Server das Passwort des Benutzers so heist dies das der Benutzer in irgendeiner Form immer das Paswot lesbar übers INet übertragen muß. Das ist unsicher.

Die Datenbanken auf dem Server sollten mit einem Passwort verschlüsselt sein, egal was darin steht. Wird diese DB gestohlen muß man erstmal diese DB entschlüsseln können. Dazu sollte man eine Hardwarebasierte Lösung benutzen, also zb. SmartCards.

Als sehr gutes Loginsystem gilt das SRP Verfahren. Bis auf den sensiblen Registratonsprozess eines neuen Benutzers gilt dieses als sehr sicher vor allen bekannten Angriffen. Der Registrationsprozess ist immer ein Problem, bei jedem Verfahren.

Gruß Hagen

**cware**

das passwort muss IMMER über das internet verschickt werden... mindestens bei der registrierung...
in der heutigen zeit ist alles andere user-unfreundlich etc. pp.

für das eigentliche einloggen kann man ein challenge-response-verfahren benutzen...
das problem ist nur: sowas unterstützt HTTP nicht...
somit bleibt im web nur die übertragung des passwortes...

cheers...

**Meflin**

Zitat von franktron:

Also bei unseren Servern wird nachdem 5 misslungenen Versuch die IP auf eine Banlist geschrieben womit die Firewall die IP 24 Std. Blockt.

Na dann viel Spass beim Bruteforce man sieht sich in ca. 10 Jahren wieder

Hilft ja nichts wenn dir einer einen Datenbank-Dump klaut, dann Brute-Forced derjenige nämlich fröhlich auf seinem Cluster im Keller vor sich hin

**Chewie**

Zitat von cware:

für das eigentliche einloggen kann man ein challenge-response-verfahren benutzen...
das problem ist nur: sowas unterstützt HTTP nicht...
somit bleibt im web nur die übertragung des passwortes...

cheers...

Wieso sollte das bei HTTP nicht realisierbar sein? Klar, interaktionslos geht es nicht, aber in zwei Schritten (1. Schritt: Laden einer Seite mit dem Challenge-Wert; 2. Schritt: Senden der Loginkennung und des Ergebnisses) sollte das doch problemlos möglich sein.

Aber natürlich löst das viele andere Probleme nicht, man würde zwar beim Login keine Passworte mehr im Klartext über die Leitung senden, aber zumindest beim Registrieren muss man das tun. Oder aber man verwendet für das Registrieren eine Diffie-Hellmann-artiges Verfahren, was aber auch nichts bringt, da in einem kabelgebundenen Netz so gut wie nicht zwischen Mitlauschen und (aktiven) Man-in-the-Middle-Attacken unterschieden werden kann und das DH-Verfahren ohne so etwas wie Zertifikate notorisch unsicher ist.

Also kommt man, will man ein System halbwegs sicher machen, nicht um die Verwendung einer komplexen Infrastruktur herum, und selbst dann bleibt immer noch das grundlegende Problem der assymetrischen Verfahren: Der Zwang zum Vertrauen der Herkunft.

**cware**

möglich wäre es evtl. dadurch, dass der challenge-wert als hidden input im formular steht...
dann würde der user das passwort eingeben und auf einloggen klicken...
dann müsste das passwort zuerst via JavaScript genommen werden, aus dem Passwort und dem challenge-wert der response-wert ermittelt werden...
und dann müsste man evtl. nochmal ein commit machen, um den response-wert als passwort zurück zu schicken...

jemand bock das mal eben umzusetzen?

cheers...

**Chewie**

Zitat von cware:

möglich wäre es evtl. dadurch, dass der challenge-wert als hidden input im formular steht...
dann würde der user das passwort eingeben und auf einloggen klicken...
dann müsste das passwort zuerst via JavaScript genommen werden, aus dem Passwort und dem challenge-wert der response-wert ermittelt werden...
und dann müsste man evtl. nochmal ein commit machen, um den response-wert als passwort zurück zu schicken...

Richtig, genauso würde das gehen, es würde aber wie angesprochen nicht viel bringen, da ja das Passwort irgendwann einmal ausgehandelt werden muss

**negaH**

Ganz stimmt das nicht.

In meiner SRP Implementierung habe ich gezeigt das man mit einem mehrstufigem EMail basiertem Registrationsprozess auch diesen Prozess kryptographisch absichern kann. Dabei wird der neuangelegte Account auf dem Server stufenweise in seinen Zugriffsrechten inkrementiert. Als erstes wird über die EMail ein Benutzer einen Account beantragen. Der Server erzeugt ein Zufallspasswort für diesen neuen Account, richtet eine vorläufigen und zeitlich begrenzten Account ohne Zugriffsrechte ein. Dann sendet er dieses vorläufige Passwort an die EMail des Benutzers als Link. Dieser wird den Link anklicken und sich das erste Mal beim Server mit dem vorläufigen Passwort anmelden, bei diesem Schritt definiert er sein reales Passwort als neues Passwort. Der Server gestattet Zugriff auf den Account, beide authentifizieren sich gegenseitig auf Basis des Registrationspasswortes. Der Server trägt die Daten zum neu gewählten Passwort in seiner DB ein, statt des dort gespeicherten vorläufigen Passwortes. Nun sendet der Server die "Prüfcode" per EMail an den User und gleichzeitg wird der "Prüfcode" auch nach dem Logindialog angezeit. Da SRP auf Diffie Hellman beruht, die "Prüfcodes" ebenfalls, und meine SRP Implementierung einen unverfälschbaren Login-Counter enthält kann ein Benutzer eine Man In The Middle Attack erkennen. Bei einer erfolgreichen Attacke wird der Angreifer ein neues Passwort hinterlegen und den Login-Counter inkrementieren. Der berchtigte Benutzer wird beim nächsten mal entweder einen fehlerhaften Login durchführen oder aber den Login-Counter zu weit inkrementiert vorfinden. Das System ist nicht absolut wasserdicht. Nimmt man eine "allmächtige" Autorität an, die JEDE Kommunikation überwachen kann, also auch TrustCenter, SmartCard Produktion, Post, INet, EMail, dann wird es kein automatisiertes Verfahren geben können das nicht geknackt werden könnte durch eine MITMA. Nur ein inoffizielles persönliches Treffen der beteiligten Parteien wäre dann noch sicher.

Man kann also SRP so abändern das es im Vergleich zu 90% der heute benutzten Verfahren wirklich sicher ist. Besonders da man SRP so abändern kann das ein Benutzer bei jedem Login ein neues Passwort definieren kann ohne das der Server dies detektieren kann. Dh. eine Passwortänderung ist anonym. Das Passwort selber wird beim SRP niemals übertragen, verlässt also den Clientrechner nicht. Auch das eventuell neue Passwort wird niemals übers Netz übertragen. Dies ist möglich da SRP ein abgewandeltes Diffie Hellman benutzt.

Man handelt also kein Passwort mehr aus indem man es in irgendeiner Form über das INet versendet. Das einzigste Passwort das quasi abgefanhen werden kann und mit der man dann eine MITMA machen könnte ist das vorläufige Registrationspasswort das der Server per Zufall erzeugt und zum Client zb. pr EMail sendet. Da der dazugehörige Acccount aber noch garnicht aktiviert wurde auch nicht explizit durch den Benutzer verifiziert wurde, ist eine MITMA viel schwieriger. Man müsste dazu eben eine "allmächtige" Authorität sein. Nur würden dann Zertifikate von TrustCentern ebenfalls knackbar sein.

Gruß Hagen

**Chewie**

Ich versteh das Verfahren nicht, zunächst scheitert es schon an diesem Punkt:

Zitat von negaH:

Dieser wird den Link anklicken und sich das erste Mal beim Server mit dem vorläufigen Passwort anmelden, bei diesem Schritt definiert er sein reales Passwort als neues Passwort.

Was meinst du "sein reales Passwort"? Das Passwort, das er gerne haben würde? Und wie trägt er dieses auf dem Server ein, ohne es zu übertragen?

**cware**

ohje ohje... was das denn?
sorry, aber es ist ja wohl mit das leichteste, E-Mails abzufangen...
damit erzeugst du eine race-condition, die ein Man-in-the-Middle jedes Mal gewinnen kann...
wer hindert ihn daran, den registrierungsprozess für den eigentlichen Benutzer fortzuführen?

was ich wirklich interessant finde, ist der ansatz auf

http://pajhome.org.uk/crypt/md5/auth.html (suchen nach "Alternative System")...
der müsste jedoch noch gegen einen man-in-the-middle (MITM) abgesichert werden...
aber zumindest entfällt hier die passwort-übertragung bei der Registrierung...
wirklich toll...

cheers...