Sicherheit bei md5 ()

[zer0]

Wie schaut es eigentlich bei Captcha-Sicherheitsgrafiken aus. Derzeit wird die Grafik angezeigt und gleichzeitig beim User ein Cookie mit dem Code gespeichert. Im Anschluss wird dann verglichen, ob der eingegebene Code dem Code im Cookie entspricht. Sollte man hier lieber mit einer Session arbeiten?

Macht man doch auch Macht ja sonst kein Sinn wenn der Client den Code aus dem Cookie der Clientseitig gespeichert wird auslesen kann!

 

[Frezl]

Was ich aus meiner Informatik-Vorlesung noch weiß:

1. Doppelt zu hashen ist Unsinn, wenn ich damit gleiche Hashes vermeiden will. Denn zwei gleiche Hashes noch einmal gehashed ergibt wieder zwei gleiche Hashes. Logisch, oder? Man kann damit vielleicht Hacker verwirren, die einfaches Hashing erwarten. Aber bei Open-Source-Produkten kann man das ja leicht rausfinden.
2. Wenn man an einen Hash einen neuen String (z.B. UserID) anhängt und danach noch ein Mal hashed, ist die Chance nicht geringer, dass man einen doppelten Hash erzeugt. Hashes haben bei md5() immer die gleiche Länge. Damit verbessert dieses Vorgehen nichts. Was aber evtl helfen würde, wäre die ID mit fester Länge (also ggf. mit Nullen auffüllen) an den erzeugten Hash dranhängen und danach nicht noch ein Mal hashen. Das dürfte das Problem der Kollisionen lösen, wenns wirklich eindeutige IDs sind.

Aber: Wie bereits erwähnt wurde ist die Wahrscheinlichkeit, dass zwei gleiche Hashes auftreten, verschwindend gering. Man kann diese Wahrscheinlichkeit noch geringer machen, indem man z.B. eine eindeutige UserID oder auch den Timestamp an den Hash dranhängt. Aber welchen Vorteil könnte ein Hacker aus zwei gleich gehashten Passwörtern ziehen, wenn er nicht weiß, bei welchen Accounts das der Fall ist?

Zum Thema Session-Management kann ich dir auch schwer die PHP-eigenen Methoden empfehlen. Ich dacht immer, Sessions seien kompliziert. Aber das stimmt überhaupt nicht, weil PHP sich eigentlich um alles (eindeutige Session-IDs etc.) kümmert.

Viele Grüße,
Frezl

 

[Kai008]

Aber: Wie bereits erwähnt wurde ist die Wahrscheinlichkeit, dass zwei gleiche Hashes auftreten, verschwindend gering. Man kann diese Wahrscheinlichkeit noch geringer machen, indem man z.B. eine eindeutige UserID oder auch den Timestamp an den Hash dranhängt.

Der Meinung bin ich nicht. Wenn ein Angriff auf den Hash stattfindet, wird der Angreifer diesen mit sehr hoher Warscheinlichkeit bereits besitzen. Und da MD5-Hashes eine fixe Länge besitzen und Hexadezimal sind, und die Userid bzw. der Timestamp (warscheinlich) nur Numeric, ist es sofort klar, das er künstlich verlängert wurde, und mit ein wenig Pech erkennt man auch auf einem Blick, was zusätzlich dabei ist.
Ach ja, der TimeStamp fällt sowieso weg, da der mit hoher Warscheinlichkeit bei jeden Login einen anderen Wert hat.

 

[timestamp]

Eine kleine Frage, woher willst du bei einem Hashwert "mit ein wenig Pech" erkennen ob eine Userid oder ein Timestamp, bzw ob überhaupt etwas angehängt wurde?

 

[Kai008]

Wenn die Länge des Hash größer als 32 Zeichen ist, sofern man weiß, das es md5 ist.
Wenn nicht, kann man es ja auch mit den typischen Längen (40, 64, 96, 128) vergleichen, und so erkennt man eventuell nachträgliche Manipulationen.

Gehen wir jetzt mal vom Hash von Tutorials.de aus:

e3caf7cd74e93ce7fd80e783ebcd24d6

wenn wir jetzt den momentanen Timestamp (ms) anhängen:

e3caf7cd74e93ce7fd80e783ebcd24d61279058385856

Erkennt man meiner Meinung nach sofort, das hinten etwas anderst ist.
Der letzte numerische Teil hat eine Länge von 14 Zeichen. Wenn wir diese entfernen, bleiben nur noch 31 Zeichen übrig. Also lasse ich die 6 dran, damit der Hash eine typische Länge (eben 32 Zeichen) besitzt. Danach jage ich sie kurz durch meine Rainbow-Tables. Falls dort nichts gefunden wird, setze ich halt mein Clusterchen drauf an. Bin ja noch jung.

Zwar ist Tutorials.de mit 12 Mixalpha-Symbolic-Zeichen fast nicht auf "natürlichen Weg" knackbar, aber ich als Angreifer wüsste das natürlich nicht. (Sonst würde ich den Plain ja kennen und das Ganze wäre sinnlos.)

Hört sich zwar vielleich ein wenig seltsam an, aber ist für verspielte Menschen eine lustige Freizeitbeschäftigung.

 

[RudolfG]

Erkennt man meiner Meinung nach sofort, das hinten etwas anderst ist.
Der letzte numerische Teil hat eine Länge von 14 Zeichen. Wenn wir diese entfernen, bleiben nur noch 31 Zeichen übrig. Also lasse ich die 6 dran, damit der Hash eine typische Länge (eben 32 Zeichen) besitzt. Danach jage ich sie kurz durch meine Rainbow-Tables. Falls dort nichts gefunden wird, setze ich halt mein Clusterchen drauf an. Bin ja noch jung.

...

Irgendwie hast du entweder die Beiträge nicht richtig gelesen oder einfach nur nicht verstanden. Keiner sagte was von an dem Hash dranhängen, sondern an Klar-Text dranhängen und danach hashen

Z. B.

Tutorials.de

Hash: e3caf7cd74e93ce7fd80e783ebcd24d6

Tutorials.de14.07.2010

Hash: c81bc47d1b037919c3cb176d8309d380

Beide sind als Hash gleich lang, also wirst weder du noch sonst irgendeiner der nicht weiß wo und was an dem Klar-Text modifieziert wurde, irgendetwas erkennen können.

Gruß
RudolfG

 

[Kai008]

Ach so. Dann habe ich Frezl falsch verstanden.

Man kann diese Wahrscheinlichkeit noch geringer machen, indem man z.B. eine eindeutige UserID oder auch den Timestamp an den Hash dranhängt.

 

[RudolfG]

Ok Sorry, das ist natürlich sehr sehr unglücklich ausgedrückt.

 

[timestamp]

Ich hab es eigentlich so gemeint:

echo md5("Geheimes Passowort"); //230D4BF8EED22AF2570F7A4C3DC8971B
echo md5( "Geheimes Passwort".USERID );//30A68BF019FC95B8CA83C22320C1DCBC

Und schwupps hat man ein Salt erstellt

 

[Navy]

Doppelt zu hashen ist unnötig. Wenn ein Angreifer in Deinem Fall die Hashes eines auslesen kann, dass ist er bereits auf dem System und liest in der DB. Die Verwendung eines Salt bei einmaligen hashen ist also völlig ausreichend.