Sicherheit bei md5 ()

[Sasser]

Guten Abend!

Ich habe zwei Fragen, welche sich aber auf den selbe Problem beziehen.

Passwörter verschlüssele ich per md5 () und schreibe Sie in eine Datenbank:

$password = md5 ( $password );

Ich speichere bei eingeloggten Usern ein Cookie mit einer SessionID ab und diese erzeuge ich so (wird vorher überprüft, ob bereits ein User dieselbe hat):

$sessionID = md5 ( uniqid ( rand (), true ) );

Wie sicher sind nun diese beiden Beispiele in Hinsicht darauf, dass z.B. bei verschiedenen Passwörtern nicht der gleiche Hash herauskommt? Wie könnte ein Hacker dies überlisten und sich einen Vorteil hieraus schaffen?

Über Verbesserungsvorschläge bin ich sehr dankbar!

 

[styler2go]

Manche Boards (MyBB zbs.) machen einfach 2 mal md5.
D.h. md5(md5($pw)); ob das sicherer ist, ist zu bezweifeln, aber das sehe ich öfters mal.

Wieso legst du die sessionid selbst fest? dazu gibt es doch die session_start() & session_id()?

 

[Kai008]

MD5 gilt in Fall von Kollisionen als geknackt. Allerdings lassen sich damit eher Signaturen und keine Passwörter angreifen. Generell brauchst du dir dabei keine Gedanken machen, da ist die Warscheinlichkeit wesentlich höher das jemand den Hash brutet und so auf eine Kollision stößt.

Das mit der Session verstehe ich nicht. PHP besitzt doch eine Methode, die einen eine eindeutige Session zurückgibt, mit der man serverseitig dann Werte speichern kann. Warum machst du dann sowas?

Und Hacker schaffen sich keine Vorteile.

 

[Sasser]

Also ich generiere eine SessionID und lege diese als Cookie beim User ab. Darüber kann ich dann bestimmte Datenbankabfragen machen und z.B. auch besser festhalten wann dieser Online war, ohne Log-Dateien auswerten zu müssen.

Also sehe ich das richtig, dass mein Vorgehen sicherheitstechnisch kein Problem darstellt?

 

[styler2go]

Ja, so macht es denke ich fast jeder der ein Login nutzt.
Nochmal zur Info: So mache ich das mit session_id() nicht mit einer slebst generierten:

$sql = "UPDATE user SET UserSession='" . session_id() . "', lastaccess='" . time() . "', lastlogin='" . date('d.m.Y') . "' WHERE id=" . $userid;
mysql_query($sql);

 

[RudolfG]

Hi Sasser,

also ich habe in einer Awendung (ist zwar C++ aber spielt hier überhaupt keine Role!), auch das gleiche Problem. Ich habe es so gelöst, dass jetzt vor dem hashen immer die Benutzer-ID an das Passwort angehängt wird und dann geshasht wird. Sollten jetzt zwei Benutzer das gleiche Passwort haben, gibt es trotzdem einen anderen Hash da der Passwort-String um die "eindeutige" Id erweitert wurde (macht natürlich nur Sinn wenn die ID unique z.b. Primary key ist!).

Beispiel:

Beide Benutzer haben, dass Passwort "geheim" gewählt, dies sieht man allerdings nicht. Da an das Passwort noch die ID gehangen wurde z. B. bei Benutzer mit ID 1 wurde aus "geheim" -> "geheim1" bei Benutzer mit ID 2 wurde aus "geheim" -> "geheim2" usw.... bevor es gehasht wurde.

ID | Benutzer | passwort
1 | rudolf | 8402c9af51cd47de57ace27a06061488
2 | test | ccb1ef2f3b00d0299144ee0ecca3af01

Nähere Informationen zu Salt findest du hier.

Klar wenn der Anwender den Salt kennt (also was und wo du es an dem String anhängt) kann er natürlich wieder die Passwörter auf gleicheit Überprüfen. Deswegen sollte man den Salt geheim halten.

Hoffe etwas geholfen zu haben.

Gruß
RudolfG

 

[Steiner_B]

Aber die eigentliche Sicherheitslücke in der ganzen Anwendung ist die Übertragung vom Textfeld bis zum Server. PHP arbeitet serverseitig, das heißt dein Passwort wird im Plaintext an den Server gesendet und dann dort verschlüsselt. Somit kann jeder Hacker mit einem einfachen Netzwerksniffer das Passwort mitlesen.

 

[Sven Mintel]

Somit kann jeder Hacker mit einem einfachen Netzwerksniffer das Passwort mitlesen.

Naja, ins Netzwerk muss der Hacker aber vorher auch erstmal rein

 

[Flex]

Aber die eigentliche Sicherheitslücke in der ganzen Anwendung ist die Übertragung vom Textfeld bis zum Server. PHP arbeitet serverseitig, das heißt dein Passwort wird im Plaintext an den Server gesendet und dann dort verschlüsselt. Somit kann jeder Hacker mit einem einfachen Netzwerksniffer das Passwort mitlesen.

Deshalb wird auf Seiten, bei denen sicherheitsrelevante Daten verarbeitet werden, SSL benutzt.

 

[Sasser]

Also der User hinterlegt brisante Informationen und aus diesem Grund wird ohnehin standartmäßig und unumgänglich mit einer 256-Bit SSL Verschlüsselung gearbeitet.

Weil es gerade zum Thema passt:

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?