Sunnyboy schrieb:
Und wie kann ich das Ganze nun im Quelltext einbauen?
Die Idee ist, nicht das Passwort in Reinschrift im Code zu speichern, sondern die Rückgabe einer Hashfunktion mit dem Passwort als Parameter. Jede Passwort-Eingabe während des Logins wird dann ebenfalls durch die Hashfunktion geschickt. Falls es sich bei der Eingabe um das Originalpasswort handelt, sind die Rückgabewerte gleich.
Der Rückgabewert der Hashfunktion lässt jedoch keine Rückschlüsse auf die entsprechende Eingabe zu. Das heißt, ich kann aus einem Hashwert nicht das Originalpasswort ermitteln. Wenn ich also den Hashwert kenne, weiß ich deshalb noch nicht, welches Passwort ich eintippen muss, um diesen Hashwert zu generieren.
Ein Beispiel für eine Hashfunktion:
PHP:
function myHashFunction($input)
{
$salt = 'ZufälligeBytefolgezumSchutzvorRainbowTables!';
return hash('sha512', $input . $salt);
}
Durch diese Hashfunktion schickst du nun einmal dein gewünschtes Passwort. Meinetwegen:
PHP:
echo myHashFunction('BesondersschönistdieiberischeHalbinselimFrühling.');
Das gibt dir je nach Hashfunktion eine mehr oder weniger lange Ausgabe. Bei sha512 ist es eine eher lange (512 Bit = 64 Byte). Ich füge sie hier nur abgeschnitten ein (Rückgabe in hexadezimaler Schreibweise):
Das Originalpasswort kannst du jetzt sicher in deinem Kopf verstauen, für die Anwendung ist nur noch dieser Hashwert interessant. Diesen vergleichst du mit dem Rückgabewert der Hashfunktion für eine Passwort-Eingabe.
PHP:
if (isset($_POST['password'])) {
if ('1417fb2...bcf07f' === myHashFunction($_POST['password'])) {
echo 'Korrekt!';
} else {
echo 'Falsch!';
}
}
Wenn ich als Angreifer jetzt diesen Code sehe, weiß ich noch immer nicht, was ich als Passwort eingeben muss, da ich keine Ahnung habe, welche Zeichenkette den entsprechenden Hashwert erzeugt.
* * *
Der folgende Teil ist arg
(und für so ziemlich jeden privaten Anwendungsfall völlig unerheblich).
Das ist der Grund für die Nutzung von Salts, welches Hash verfahren hier genutzt wird ist bei deiner Aussage völlig egal.
Hier eine Diskussion auf Stack Overflow, die dieses Thema behandelt:
-
Is MD5 really that bad? - Stack Overflow
Kurzversion: Was zum Knacken des Logins durchgeführt werden müsste, ist eine "
first preimage attack". Der Angreifer kennt zu einem unbekannten Passwort
P den Hash
H(P) und sucht nun eine Eingabe
P', für die gilt
H(P) = H(P'). Ob
P = P' gilt, ist dabei irrelevant. Auch der Salt ist, da dem Angreifer bekannt, zu vernachlässigen. Der Salt verhindert allerdings den Einsatz einer Rainbow Table. Das bedeutet, es müssen per brute force alle Möglichkeiten durchgegangen werden, bis ein
P' gefunden wird, das die Bedingung erfüllt.
Diese Angriffsmethode ist prinzipiell für jeden hinreichend guten Hash-Algorithmus ineffizient. Das schließt auch MD5 ein. MD5 kann derzeit nicht effizient per preimage attack angegriffen werden.
Jedoch ist MD5 kollisionsanfällig. Das heißt, es lassen sich verhältnismäßig schnell (hier innerhalb von Minuten) zwei selbstgewählte Eingaben P und P' finden, die denselben Hashwert ergeben. Ob das die "Preimage-Sicherheit" beeinflusst, ist allerdings nicht bewiesen.
Es reicht jedoch aus, um alle Welt dazu zu bringen, vom Einsatz von MD5 abzuraten.
Auf Stack Overflow zitiert jemand das Fazit eines Artikels. Ein Ausschnitt daraus:
Even though MD5 might be safe under certain scenarios, unless you absolutely have to use it for reasons such as backwards compatibility or interoperability don’t. There is no point and as Schneier always says “Attacks never get worse, they only get better”.
