html-LogIn: Passwort mit md5

[jens]

Beim Apache gibt es ja irgendwie die Möglichkeit ein "digest authentication" durchzuführen. Dabei wird das Passwort nicht direkt in Klartext, sondern als MD5 Prüfsumme übermittelt.

Ich gehe doch recht in der Annahme, das der Browser das Passwort in MD5 wandelt, oder?

Kann man diesen Mechanismus auch dazu nutzen ein Passwort, welches in einem normalen HTML-Formular eingegeben wird, vom Browser als md5 übermitteln zu lassen?

Ich kenne nur die etwas doofe Variante, das durch ein JavaScript erledigen zu lassen Das funktioniert schon recht gut, aber ist halt etwas umständlich...

Bei heise.de wird teilweise der Login vom Browser erledigt. d.h. Man bekommt diese Typische Eingabemaske vom Browser, wie es auch bei einer .htaccess-Auth passiert. Ich kann mir aber nur schwer vorstellen, das dahinter wirklich eine .htaccess-Datei steckt Ist da evtl. ein mod_auth_digest für den Apache im Spiel?

[gerold]

Hi jens!

Leider keine Antwort, nur ein Gedanke:
Wenn die md5-Summe nur vom Passwort gemacht wird und nicht noch ein anderer Wert zusätzlich dafür verwendet wird, dann ist es doch egal, ob ich das Passwort ausschnüffle oder die md5-Summe. Mit beiden kann ich mich dann am Server identifizieren???

Dann wäre die md5-Summe nur ein Schutz, wenn ich mich mit dem Passwort auch an andere Server anmelden könnte und die anderen Server diese Art der Authentifizierung NICHT unterstützen.

Ich kenne diesen Mechanismus noch nicht, aber korrigiert mich wenn ich falsch liege.

lg
Gerold

[jens]

Da hast du durchaus recht. Ich hatte mal eine Idee dazu.

Wenn ich mir es recht überlege ist eine Auth-Geschichte ohne SSL/https immer unsicher. Da ist es egal ob Daten von Client "verschlüsselt" werden. Das Problem bleibt immer das selbe. Wenn jemand den Datenstrom zwischen Server und Client abfangen kann, wird er mit den Daten immer was anfangen können.

Ganz erhlich frag ich mich nur, warum eine SSL/https verschlüsselung wirklich sicher ist, denn wenn man den kompletten Datenstrom abfangen kann, sollte man damit doch auch was böses anfangen können, oder? Naja, vielleicht weiß ich davon auch zuwenig.

Dennoch ist eine Clientseite berechung der MD5 Summe vom Passwort schon ganz gut, denke ich. Wie du auch schon festgestellt hast, wird das Passwort evtl. woanders noch genutzt!

Um ein wenig mehr Sicherheit auf dem Server zu erhalten kann man, das Passwort nicht direkt als MD5 zu speichern, sondern davon wieder eine MD5 berechen zu lassen und nur diese speichern.
Sollte jemand Zugriff auf die SQL-DB erlangen, kann er mit den MD5 Prüfsummen nicht direkt was anfangen... Aber naja, wer zugriff auf die SQL-DB hat, kann die Daten ja eh direkt dort verändern

[jens]

Leider keine Antwort, nur ein Gedanke:
Wenn die md5-Summe nur vom Passwort gemacht wird und nicht noch ein anderer Wert zusätzlich dafür verwendet wird, dann ist es doch egal, ob ich das Passwort ausschnüffle oder die md5-Summe.

Warte mal das bringt mich nun auf eine Idee!

Angenommen, es wird vom Server eine Zufällige Zahl mitgeschickt. Diese wird zur berechnung des Passwort-MD5-Wertes herrangezogen. Somit wäre die MD5 Summe immer eine andere. Der liebe Hacker kann damit also nicht's anfangen.
Nun haben wir aber ein Problem auf dem Server! Da müssen nämlich die Passwörter im Klartext vorliegen. Ansonsten kann der Server ja nicht die MD5 Summe des Clients überprüfen!

Das ist definitiv schon eine bessere Lösung, aber immer noch unschön, wegen den Klartext Passwörtern auf dem Server!

Dafür hätte ich aber evtl. auch noch eine Idee
Was ist, wenn man quasi zwei Passwörter hätte? Das eine wird mit der Zufallszahl des Server als MD5 übertragen das andere als Klartext.

Mit dem Klartext-Teil wird auf dem Server das "original" Passwort ver-/entschlüßelt. Somit liegt es auf dem Server nicht mehr in Klartext vor!

EDIT: Da zwei Passwörter doof sind, könnte man vielleicht das vorhandene aufteilen! Man bildet daraus zwei MD5 Schlüssel, eins mit Zufallszahl, das andere ohne

[jens]

So hab mal die Verfahren aufgeschrieben:

Auth.Verfahren - User erstellen:

• 1. Client:
  • 1.1. User füllt Formular mit Name und Passwort aus.
    1.2. per JS: bilden aus ersten vier Zeichen eine MD5 Summe
    1.3. MD5 Summe + rechlichen Zeichen des Passworts zum Server schicken
  2. Server:
  • 2.1. restliche Zeichen des Passworts mit geschickter MD5 Summe verschlüsseln
    2.2. verschlüßeltes Passwort und sonstige Userdaten in DB eintragen

Auth.Verfahren - Client Login:

• 1. Client: schickt login-Anfrage
  2. Server:
  • 2.1. setzt SessionID per Cookie
    2.2. generiert Random-Zahl
    2.3. speichert Random-Zahl mit SessionID in DB
    2.4. schickt LogIn-Form mit Random-Zahl zum Client
  3. Client:
  • 3.1. eingetipptes Passwort wird aufgeteilt ersten vier Zeichen | rechtlichen zeichen
    3.2. erstellung der MD5 Summen:
    - MD5( ersten vier Zeichen)
    - MD5( rechlichen Zeichen + die Random-Zahl vom Server )
    3.3. sendern des Usernamens (Klartext) + beide MD5-Summen
  4. Server:
  • 4.1. mit der ersten MD5 Summe wird das Passwort aus der DB entschlüsselt
    4.2. Random-Zahl per SessionID aus der DB holen
    4.3. mit dem entschlüsselten Klartext-Passwort und der Random-Zahl wird eine MD5 Summe gebildet
    4.4. vergleichen der zweiten MD5 summe vom Client und der gebilteten

Das werde ich mal versuchen in PyLucid CMS umzusetzen

[Joghurt]

Wenn ich mir es recht überlege ist eine Auth-Geschichte ohne SSL/https immer unsicher. Da ist es egal ob Daten von Client "verschlüsselt" werden. Das Problem bleibt immer das selbe. Wenn jemand den Datenstrom zwischen Server und Client abfangen kann, wird er mit den Daten immer was anfangen können.

Nein. Stelle es dir einfach so vor:

SSL benutzt public-key Cryptography, d.h. jeder hat einen privaten und einen öffentlichen Schlüssel. Mit dem öffentlichen kann man verschlüsseln, mit dem privaten entschlüsseln.

Client und Server tauschen nun untereinander nur die publics aus. Danach werden Übertragungen Client->Server so verschlüsselt, dass nur der Server sie entschlüsseln kann, und umgekehrt.

Der ganze Grundgedanke von sichereren Verbindungen ist ja, dass jemand, der alles mitschneidet, trotzdem mit den Informationen nichts anfangen kann. (Und auch nicht Daten mit einstreuen kann, ohne das dies bemerkt wird)

[jens]

Das werde ich mal versuchen in PyLucid CMS umzusetzen

Es ist fertig und testen könnt ihr es auch: http://www.python-forum.de/viewtopic.php?p=20070#20070

[jens]

So hab mal die Verfahren aufgeschrieben:

Auth.Verfahren - User erstellen:

• 1. Client:
  • ...
    1.2. per JS: bilden aus ersten vier Zeichen eine MD5 Summe
    ...

Auth.Verfahren - Client Login:

• ...
  3. Client:
  • 3.1. eingetipptes Passwort wird aufgeteilt ersten vier Zeichen | rechtlichen zeichen
    ...

Hab mir jetzt noch mal überlegt, das man es besser machen kann ohne super viel Aufwand.

Warum das Klartext-Passwort aufteilen??? Warum nicht erstmal aus diesem eine MD5 Summe berechnen und dann mit dem Verfahren so wie es jetzt ist weiter machen?

Hätte den Vorteil, das nicht die Hälfte des Klartext-Passwortes zum Server gesendet wird, sondern die Hälfte der MD5 Summe!

Ein weiterer Vorteil: I.d.R. die die MD5 Summe länger (mehr Zeichen) als das Klartext Passwortes. Die nachfolgenden Schritte "funktionieren" somit besser...

Hab gleich mal ein kleines Ticket geschrieben, damit ich das nicht vergesse: http://pylucid.net/trac/ticket/20

[N317V]

Irgendwie hab ich noch nicht verstanden, welches Problem Du lösen möchtest.

[jens]

Ich möchte ja kein Problem lösen. Ich möchte nur das Verfahren verbessern, das ist alles

Aber dazu brauche ich Zeit und es gibt wichtigere PyLucid-Tickets

Ich wollte hier nur mal meine Idee zur Diskussion stellen...