MD5 Algorithmus liefert verschiedene Ergebnisse

[kleener Mann]

Hallo
Ich will meine Datenbank nun durch MD5 sichern und habe
deshalb folgendes gemacht. ICh habe die Passwörter in PHPMyAdmin
durch die Funktion MD5 in einen MD5 code umgewandelt. Dann habe
ich ein Formular gemacht, welches mir das eingegebene Passwort in
MD5 code umbauen soll. Doch der MD5 Code den mein Formular erzeugt, ist nicht der aus der Datenbank. ICh habe hier in SelfHTML mal das gesuchte Wort eingegeben und es stimmt mit dem aus der Datenbank überein. ICh habe den Code exakt so kopiert wie er da stant. Hier
mein Code:
  function SetToMD5AndSend()
  {
     document.login.pass.value = MD5(document.login.pass.value);
     document.writeln(MD5(document.login.pass.value));
     //document.login.submit();
  }
Diese Funktino wird durch onClick eines Buttons aufgerufen.
Ich hoffe ihr könnt mir helfen
kleener MAnn

[Christoph]

Hallo

Hallo

so ganz was du willst versteh ich nicht so Recht.

du sagst erst:

Doch der MD5 Code den mein Formular erzeugt, ist nicht der aus der Datenbank.

dann aber:

und es stimmt mit dem aus der Datenbank überein.

Ja was denn nun?

MD5 ist ein Zufallsalgorithmus, der zufällig daraus ein neues Passwort macht! Es wird nie das gleiche rauskommen! Denn dann könnte es man ja zurückverfolgen!

Ich hoffe ihr könnt mir helfen
kleener MAnn

Gruß Christoph

[kleener mann]

Ich meine selfHTML bekommt dasselbe raus wie PHP MyAdmin. In meinem Formular kommt aber etwas anderes heraus. Und das mit dem Zufall stimmt nicht, jeder begriff hat sein Gegenstück als MD5 code, was sich nie verändert.

[guelcki]

Moin!

@Christoph

Also da muß ich dir mal wiedersprechen. MD5 liefert keinen Zufallswert. Jedesmal wenn man einen exakt gleichen String (der noch so lang sein kann) mit MD5 hasht, kommt der gleiche Wert raus. Ansonsten hätte MD5 ja überhaupt keinen Sinn. Es stimmt nur, dass man aus einem MD5 Hash nicht zurück zum Ausgang kommt.

@ kleener Mann

Ist der MD5 Hash, den dein Formular rausgibt denn so lang, wie der in der Datenbank? Wenn nicht, ist eventuell dein Textinputfeld zu kurz, so dass die letzten Stellen des Hash abgeschnitten werden.

Howdi
gülcki

[Christoph]

Moin!

Hi

@Christoph

Also da muß ich dir mal wiedersprechen. MD5 liefert keinen Zufallswert. Jedesmal wenn man einen exakt gleichen String (der noch so lang sein kann) mit MD5 hasht, kommt der gleiche Wert raus. Ansonsten hätte MD5 ja überhaupt keinen Sinn. Es stimmt nur, dass man aus einem MD5 Hash nicht zurück zum Ausgang kommt.

jo stimmt, sorry mein Fehler...

Howdi
gülcki

LG Christoph

[kleener mann]

lol bin ich blöd, tut mir leid, dass ich das überhaupt gefragt habe. Kein wunder, dass es nicht geht wenn ich es vorher schon umwandel.
Gru´ß
kleener Mann

[Sven Rautenberg]

Moin!

lol bin ich blöd, tut mir leid, dass ich das überhaupt gefragt habe. Kein wunder, dass es nicht geht wenn ich es vorher schon umwandel.

Eben, es ist absolut sinnlos, das Passwort per Javascript vorher schon umzuwandeln. Wenn du sowas machen würdest, dürftest du hinterher auf dem Server die Wandlung nicht mehr machen - das würde dann aber so wirken, als hätte man einen komplexeren String als Klartextpasswort verwendet, und der Schutz von MD5, der ja im Prinzip nur das Ausspionieren der Passworte in der Datenbank durch andere Benutzer des Servers verhindern soll, wäre dahin

- Sven Rautenberg

[Andreas Korthaus]

Hi!

Wie wärs mit md5(md5($pass))? halt doppelt gemoppelt, dann sind doch alle glücklich, oder? D.h. ich "verschlüssele" immer schon beim Client, und vergleiche dann die MD5 Summe der MD5 Summe des eingegebenen Passworts mit der MD5 Summe der MD5 Summe in der Tabelle. Der Unterschied wäre derselbe wie bei http basic-auth zu digest-auth, Sicherheitsgewinn ist es nicht wirklich, macht aber die Bedienung für einen der das übertragene Passwort erspäht hat unpraktischer.
Naja.

Grüße
Andreas

[Sven Rautenberg]

Moin!

Wie wärs mit md5(md5($pass))? halt doppelt gemoppelt, dann sind doch alle glücklich, oder? D.h. ich "verschlüssele" immer schon beim Client, und vergleiche dann die MD5 Summe der MD5 Summe des eingegebenen Passworts mit der MD5 Summe der MD5 Summe in der Tabelle. Der Unterschied wäre derselbe wie bei http basic-auth zu digest-auth, Sicherheitsgewinn ist es nicht wirklich, macht aber die Bedienung für einen der das übertragene Passwort erspäht hat unpraktischer.

Eben: Sicherheitsgewinn ist es nicht wirklich. Der Sicherheitsgewinn zwischen basic-auth und digest-auth ist ja immerhin noch ein geringer, weil das Passwort, welches den Zugang gewährt, nicht im Klartext über die Leitung geht. Der Sicherheitsgewinn deiner Variante ist aber gleich NULL!

Entweder gibst du ein Klartextpasswort in das entsprechende Formularfeld ein und läßt es dann (was zwingend Javascript erfordert) in ein anderes Klartextpasswort (getarnt als MD5-Hash, aber in Wirklichkeit nur Klartext) umrechnen, was dann zum Server geht, oder man gibt gleich den MD5-Hash des eigentlichen, aber bedeutungslosen Passwortes in das Formularfeld ein und schickt es dann zum Server. Wer den MD5-Hash abfängt, kriegt damit Zugang, egal wie das eigentliche Passwort lautet.

Aufwand, damit umzugehen, ist es nicht wirklich. Ein Angreifer schaltet wahlweise einfach Javascript ab, oder baut sich eine eigene Login-Seite, oder macht sonst irgendwas - er braucht zum Login ja definitiv nur den MD5-Hash, der im Klartext über die Leitung zum Server geht.

Also warum dann solche komplizierten Konstrukte vorlagern, die zwingend Javascript erfordern?

- Sven Rautenberg

[Calocybe]

Auch Moin!

Wie wärs mit md5(md5($pass))? halt doppelt gemoppelt, dann sind doch alle glücklich, oder? D.h. ich "verschlüssele" immer schon beim Client, und vergleiche dann die MD5 Summe der MD5 Summe des eingegebenen Passworts mit der MD5 Summe der MD5 Summe in der Tabelle. Der Unterschied wäre derselbe wie bei http basic-auth zu digest-auth, Sicherheitsgewinn ist es nicht wirklich, macht aber die Bedienung für einen der das übertragene Passwort erspäht hat unpraktischer.

Eben: Sicherheitsgewinn ist es nicht wirklich. Der Sicherheitsgewinn zwischen basic-auth und digest-auth ist ja immerhin noch ein geringer, weil das Passwort, welches den Zugang gewährt, nicht im Klartext über die Leitung geht.

Aehm... ihr redet hier ueber digest-auth, wie wenn dabei einfach der MD5-Hash eines Passwortes uebertragen werden wuerde. Das ist aber nicht so. Der MD5-Hash wird bei digest-auth ueber mehrere verschiedene Sachen gebildet, die sich bei jedem HTTP-Request aendern. Deswegen kann man den Hash *nicht* wiederverwenden; es nuetzt also nichts, einen abzufangen. Siehe RFC 2617.

So long

[Sven Rautenberg]

Moin!

Aehm... ihr redet hier ueber digest-auth, wie wenn dabei einfach der MD5-Hash eines Passwortes uebertragen werden wuerde. Das ist aber nicht so. Der MD5-Hash wird bei digest-auth ueber mehrere verschiedene Sachen gebildet, die sich bei jedem HTTP-Request aendern. Deswegen kann man den Hash *nicht* wiederverwenden; es nuetzt also nichts, einen abzufangen. Siehe RFC 2617.

Nö, so reden wir eigentlich nicht. digest-auth hat leichte Vorteile gegenüber basic-auth. Aber ein formularbasiertes Login-Formular, dessen Passwort vor dem Absenden mit Javascript MD5-gehasht wurde, bietet keinerlei Vorteile gegenüber dem ungehashten Senden des Passwortes.

- Sven Rautenberg

[Calocybe]

Re!

Nö, so reden wir eigentlich nicht. digest-auth hat leichte Vorteile gegenüber basic-auth. Aber ein formularbasiertes Login-Formular, dessen Passwort vor dem Absenden mit Javascript MD5-gehasht wurde, bietet keinerlei Vorteile gegenüber dem ungehashten Senden des Passwortes.

Also ich finde, die Vorteile von digest-auth sind etwas mehr als nur "leicht". Man kann weder das Klartextpasswort erschliessen, noch kann man ein abgefangenes Passwort wiederverwenden. Oder moechtest Du vielleicht darauf hinaus, dass nur das Passwort und nicht die Seite verschluesselt uebertragen wird, wenn man nicht https benutzt?

So long