Sicherheit von gehashten Passwörtern

[Der Hans]

Ich muss mich in nächster Zeit etwas mehr mit Passwortsicherheit und sicherem Ablegen in Datenbanken auseinandersetzen und habe mir gerade ein paar Gedanken dazu gemacht. MD5 sollte man ja (zumindest ungesalzen) nicht mehr nutzen, daher habe ich mir folgendes Script als "Mehrfach-Hash" gebastelt und würde gerne wissen, ob man so oder so ähnlich Passwörter sicher schützen kann.

$user_hash = crypt($username, strrev($username));
$pw_hash = crypt($passwort, strrev($passwort));
$length = strlen($user_hash);
$combined = "";
for($i=0;$i<$length;$i++){
    $combined .= $user_hash{$i};
    $combined .= $pw_hash{$length-($i+1)};
}
$final_hash = crypt($combined, strrev($combined));

In der Datenbank würden dann $username und $final_hash gespeichert werden.

 

[sysop]

Was ist schon sicher?

MD5 ohne Salz ist auch noch möglich und "sicher".Passwörter wie abc oder root sind halt in jede r MD5 Datenbank enthalten. a!GhR1#%7fD sieht da aber schon ganz anders aus und wird wohl in keiner der Datenbanken zum Nachschlagen aufliegen.

Wenn du meherer Hashes kombinierst liegst du jedenfalls auf einer recht sicheren Welle.

 

[Asterixus]

Einen Hash anhand anderer konkreten Daten zu generieren, ist eine schlechte Idee, da diese Daten ggf. geändert werden können (Benutzername z. B.)

 

[mermshaus]

Dieser Artikel ist recht interessant:

- Coding Horror: Speed Hashing

 

[francesco]

Der Artikel »Let’s talk about password storage« ist ebenfalls lesenswert.

 

[sysop]

Ein nicht unwesentlicher Punkt, der bei "Passwort-Eingaben" immer wieder vergessen wird, ist eine Limitierung der Versuche.
Ich persönlich verwerfe Zugangscodes nach dem fünften Fehlversuch, was Wörterbücher und Datenbanken als Basis für Loginversuche fast hinfällig macht, es sei denn, die Leute gehen grob fahrlässig mit ihren Zugangscodes um.
Erlaube ich unbegrenzte Versuche, lassen sich (unter der Annahme, dass User faul sind und bequeme Passwörter einsetzen) fast alle "Passwörter" erraten.
Beim knacken eine Zugangscodes geht es doch um die umkehrbarkeit der Verschlüsselung.

Unterscheiden sollte man also, ob man ein Passwort knackt oder ob man durch Versuche die richtige Kombination errät. Dabei zählt nach meiner Meinung nur die Ausdauer. Die Wahl des Verschlüsselungsalgoithmus ist erst wesentlich, wenn man Passwörter irgendwo anzeigt.

Soll heissen, ob ich das Passwort 123 nun mit Alogotithmus A oder B verschlüssele, macht das Passwort nicht sicherer, wenn jemand unlimitierte Versuche zum herausfinden hat.

 

[mermshaus]

Das wesentliche Szenario ist wohl immer „Datenbank geklaut“.[1] Wenn wir davon ausgehen, dass die Datenbank nicht geklaut wird, brauchen Passwörter eigentlich überhaupt nicht verschlüsselt zu werden, denn dann lassen sich Mechanismen anwenden, wie sie sysop beschrieben hat.

Für den Fall, dass die Datenbank geklaut wird, besteht das Problem dann darin, dass haufenweise Kombinationen aus E-Mail/Passwort gefunden werden könnten.

Das ist kritisch, weil es den Login auf der attackierten Seite ermöglicht. Je nach Seite ist das ein größeres oder kleineres Problem. Richtig übel wird es eigentlich erst, wenn die Kombination auch zum Login in den Mail-Account eines Nutzers oder in ein ähnlich lohnenswertes System berechtigt, weil dort dasselbe Passwort verwendet wurde.

Da können unterschiedliche Verschlüsselungsalgorithmen helfen, die Zeit, die es braucht, die Passwörter zu knacken, massiv zu erhöhen.

Es ist aber nicht zuletzt auch die Verantwortung des Nutzers, einerseits sichere Passwörter zu wählen und andererseits Passwörter nicht zwischen wichtigen und unwichtigen Accounts zu teilen.



1: Oder noch allgemeiner: Dem Angreifer liegen alle Informationen vor (Hashes, Salts, Algorithmen, …) außer den Originalpasswörtern.