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:

PHP-Code:

$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):

PHP-Code:

$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!

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()?

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.

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?

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:

PHP-Code:

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


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

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.

Zitat von Steiner_B

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

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

Zitat von 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.

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

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?

Zitat von Sasser

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 :P Macht ja sonst kein Sinn wenn der Client den Code aus dem Cookie der Clientseitig gespeichert wird auslesen kann!

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

Zitat von Frezl

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.

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?

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:

Code :

1	e3caf7cd74e93ce7fd80e783ebcd24d6

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

Code :

1	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.