it-swarm.com.de

Ist die Verwendung von SHA-512 zum Speichern von Passwörtern tolerierbar?

Ich weiß, dass die besten Optionen zum Speichern von Passwörtern bcrypt/PBKDF2/scrypt sind.

Angenommen, Sie müssen ein System prüfen, das SHA-512 mit Salz verwendet. Ist das gut"? Oder ist es eine Sicherheitslücke, die behoben werden muss, obwohl Ihre Website ein Diskussionsforum ist?

Wenn es schwach ist, muss es natürlich behoben werden, da Benutzerkennwörter auch auf anderen Websites verwendet werden können. Die Frage ist - ist es zu schwach, um es nicht als Möglichkeit zu tolerieren?.

44
Bozho

Nein, Sie lösen das falsche Problem.

Der Wechsel von SHA-1 oder SHA-256 zu SHA-512 macht das Knacken des Hashs nicht wesentlich schwieriger. Hashes werden im Allgemeinen nicht mithilfe einer mathematischen Eigenschaft des Algorithmus umgekehrt, sodass die Weiterentwicklung des Algorithmus die Sicherheit nicht wesentlich verändert.

Stattdessen werden Hashes mithilfe einer "Guess and Check" -Technik brutal erzwungen. Sie erraten ein Passwort, berechnen den Hash und prüfen dann, ob Sie richtig geraten haben. Und wiederhole und wiederhole und wiederhole, bis du es endlich bekommst.

Der Weg, den Angreifer zu verlangsamen, besteht darin, den Hashing-Prozess zu verlangsamen. Wenn die Überprüfung jedes einzelnen Passworts länger dauert, kann der Angreifer nicht so viele davon erraten. In diesem Fall ist SHA-512 nicht ' t deutlich langsamer als SHA-256 oder SHA-1 oder MD5. Sie fügen also keine wirkliche Sicherheit hinzu.

Stattdessen besteht der rote Faden zwischen Techniken wie bcrypt, PBKDF2 und scrypt darin, dass alle die Hashing-Funktion immer und immer wieder ausführen, tausende Male für nur eine einzige Kennwortschätzung. Angenommen, eine Site verwendet PBKDF2 bei 10.000 Iterationen: Dies bedeutet, dass der Angreifer so viel Zeit und Ressourcen für eine einzelne Vermutung aufwenden muss, wie er es sonst für ein ganzes Wörterbuch mit 10.000 Passwörtern tun müsste. Indem Sie den Angreifer verlangsamen, begrenzen Sie die Anzahl der Passwörter, die er letztendlich erraten kann, und verringern daher die Wahrscheinlichkeit, dass er schließlich richtig rät.

Viele Installationen passen ihre Konfiguration an die vorhandene Hardware an. So verwendet beispielsweise LUKS mindestens 1000 Iterationen oder wie viele es auch dauert, um 1/8 Sekunde zu verbrauchen, je nachdem, welcher Wert länger ist.

50
tylerl

Angenommen, Sie müssen ein System prüfen, das SHA-512 mit Salz verwendet. Ist das gut"? Oder ist es eine Sicherheitslücke, die behoben werden muss, obwohl Ihre Website ein Diskussionsforum ist?

Angenommen, es handelt sich um ein langes kryptografisch zufälliges Salz pro Benutzername, und Ihre Prüfung muss keinen bestimmten gesetzlichen oder behördlichen Vorschriften entsprechen, dann würde ich ein wenig Mathematik vorschlagen.

Es ist ein Diskussionsforum, daher gehe ich davon aus, dass Benutzer ihre Passwörter niemals ändern müssen. Die grundlegenden Fragen sind also:

  • Wie lange sollte ein "normales" Passwort durchschnittlich sicher sein?
  • Was ist der angenommene Schlüsselraum eines "normalen" Passworts?
  • Mit welcher Geschwindigkeit soll ein Angreifer bei einem Offline-Angriff Passwörter ausprobieren können?

Wir haben die Grundgleichung: - Durchschnittliche Sicherheitszeit * 2 = Erschöpfungszeit des Schlüsselraums

Wir verwenden die folgenden nützlichen Gleichungen:

  • Erschöpfungszeit des Schlüsselraums * Testrate = minimaler Schlüsselraum für "normale" Passwörter
  • Minimaler Schlüsselraum für "normale" Passwörter/Schlüsselraum-Erschöpfungszeit = maximale Angriffsrate
  • mindestschlüsselraum für "normale" Passwörter/Testrate = Schlüsselraum-Erschöpfungszeit

Nehmen wir also dieses Beispiel:

  • Durchschnittlich 30 Tage Sicherheit für ein "normales" Passwort
  • "Normale" Passwörter sind die PHPBB-Leckwortliste * der Regelsatz "d3ad0ne"

Wir haben das Ergebnis:

  • 30 * 2 * 24 * 3600 = 5184000 Sekunden Schlüsselraum-Erschöpfungszeit
  • 184389 * 35408 = 6528845712 mögliche Passwörter (Schlüsselraum)
  • 6528845712/5184000 = 1259 Versuche/Sekunde ist die maximale Angriffsrate.
  • Dies ist offensichtlich unzureichend, da OclHashcat eine Rate von 797 Millionen Versuchen/Sek. Für einen einzelnen PC (8x AMD R9 290Xstock-Kerntakt) auflistet.

Wenn wir den anderen Weg gehen, haben wir:

  • "Normale" Passwörter sind die PHPBB-Leckwortliste * der Regelsatz "d3ad0ne"
  • Die Testrate beträgt 797 Millionen Versuche/Sek

So erhalten wir:

  • 184389 * 35408 = 6528845712 mögliche Passwörter (Schlüsselraum)
  • 797000000 Versuche/Sek
  • 6528845712/797000000 = 8 Sekunden.
  • Mit einem einzigen modernen Computer und diesen Schlüsselraumannahmen würden Ihre "normalen" Benutzer offensichtlich jeweils in 8 Sekunden geknackt.

Wenn Sie 1.000 Benutzer hätten, wäre dies:

  • 1000 * 8 = 8000 Sekunden oder 8000/3600 = durchschnittlich 2,2 Stunden, um alle "normalen" Passwörter aus den 1000 zu knacken.

Wenn Sie nun davon ausgehen, dass Ihre Benutzer kryptografisch zufällige 8-Zeichen-Passwörter mit Groß-, Klein- und Kleinbuchstaben auswählen (viel Glück damit!):

  • 62 ^ 8 = 218340105584896 Schlüsselraum
  • 797000000 Versuche/Sek
  • 218340105584896/797000000 = 273952 Sekunden
  • 273952/3600 = 76 Stunden. Im Allgemeinen immer noch unzureichend, aber wenn Sie die Mindestlänge nur geringfügig erhöhen können (und die perfekte Zufälligkeit und den perfekten Zeichensatz beibehalten), sind Sie in Ordnung.

Wählen Sie zuerst die sinnvollen Zahlen aus und rechnen Sie dann nach. Die Antwort wird danach offensichtlich sein.

42

Ich fürchte, es ist nicht möglich zu beantworten, ob dies in Bezug auf eine Prüfung "in Ordnung" ist oder nicht, ohne den Kontext der Organisation, die die Prüfung durchführt. Ein für ein Unternehmen angemessenes Risiko kann für ein anderes Unternehmen durchaus inakzeptabel sein.

In Bezug auf die technischen Spezifikationen Ihrer Frage. Angenommen, Sie verwenden SHA-512 mit Salz pro Benutzer, kann dies in Abhängigkeit von den Bedrohungen und den Auswirkungen eines Verstoßes als in Ordnung angesehen werden. Es ist definitiv besser als ungesalzenes MD5, aber offensichtlich nicht so gut wie bcrypt/PBKDF2/scrypt.

Es wäre relativ widerstandsfähig gegen Dinge wie Rainbow-Tischangriffe, aber nicht widerstandsfähig (wie @terrychia sagt) gegen einen dedizierten Angreifer mit hardwareunterstützten Cracking-Einrichtungen und Zeitaufwand.

Ob es für Sie in Ordnung ist, hängt davon ab, ob Sie erwarten, dass dieser Angreifer die Website angreift, und welche Auswirkungen ein Verstoß haben würde.

Wenn ein Verstoß beispielsweise einen direkten/indirekten Verlust von 1 Million US-Dollar kosten würde, wäre es eine schlechte Idee, sich auf ein Setup zu verlassen, das als nicht ideal eingestuft wird.

Wenn ein Verstoß Sie jedoch 100 US-Dollar kosten würde, würde sich die für die Implementierung des Fixes erforderliche Entwicklerzeit wahrscheinlich nicht lohnen.

31
Rory McCune

Nein, es ist nicht gut.

Einfacher SHA512 kann mit GPUs/FPGAs/ASICs ziemlich schnell brutal erzwungen werden. Wenn es überhaupt eine Möglichkeit gibt, das Problem zu beheben, ändern Sie es auf jeden Fall, um etwas wie bcrypt, scrypt oder pbkdf2 zu verwenden.

14
user10211