Frage:
Woher weiß ein Hacker, wie oft ein Passwort gehasht wurde?
NKD
2015-08-28 14:59:11 UTC
view on stackexchange narkive permalink

Ich habe viele Fragen zu Sicherheits- und Hashfunktionen auf dieser und anderen Websites gelesen. Ich bin kein Experte, nur ein neugieriger Kopf, und nach meinem Verständnis ist es umso besser, je mehr Iterationen zum Hashing eines Passworts verwendet werden, und Sie sollten eine Ausgabe erhalten, die einer Eingabe entspricht (Modulo-Kollision mit fehlerhaften Funktionen). In dieser Hinsicht ist die Ausgabe nicht dieselbe, wenn die Anzahl der Iterationen variiert.

Was ich jedoch nicht verstehe, ist, wie ein Hacker, der versucht, die Ebene zu finden, weiß, wie viele Iterationen verwendet wurden. Weil er es wissen muss oder habe ich etwas verpasst?

Keine direkte Antwort, aber die ideale Sicherheitsarchitektur funktioniert auch dann, wenn der Angreifer vollen Zugriff auf alle Implementierungsdetails hat (einschließlich der Anzahl der Hashing-Runden). Die Annahme, dass der Angreifer weiß, wie viele Runden verwendet wurden, ist also nicht unbedingt darauf zurückzuführen, dass dies üblich ist, sondern dass es immer gut ist, in Bezug auf die Sicherheit die schlimmsten Annahmen zu treffen.
Sicherheit ist eher Schach als Poker.
Kurz gesagt, ein Hacker kennt die Anzahl der Iterationen, da dies kein Geheimnis ist (wenn er Zugriff auf den Hash selbst hat).
Vier antworten:
#1
+39
SilverlightFox
2015-08-28 15:13:57 UTC
view on stackexchange narkive permalink

Die Anzahl der Runden wird häufig mit dem Passwort und dem Hash gespeichert. Verwenden Sie beispielsweise bcrypt:

  $ 2a $ 10 $ oEuthjiY8HJp / NaBCJg.bu76Nt4eY4jG / S3sChJhZjqsCvhRXGztm  

Die 10 gibt den Arbeitsfaktor an und addiert effektiv 10 Bit Entropie in Bezug auf die Hashing-Zeit für rohe Gewalt. 2 ^ 10 = 1024 Runden .

Wird mit dem Hash gespeichert, falls der Arbeitsfaktor aufgrund des Mooreschen Gesetzes erhöht werden muss.

Wenn Ihr System einen geheimen Arbeitsfaktor hat, der für alle Konten gleich ist, kann dies als zusätzliche Sicherheitsmaßnahme verwendet werden, ähnlich wie bei einem Pfeffer. Wenn ein Angreifer sein eigenes Passwort festlegen und den Hash anzeigen kann, muss er mit einem Pfeffer kombiniert werden, da er sonst die Anzahl der im Spiel befindlichen Iterationen anhand des resultierenden Hash bestimmen kann. Dies ist jedoch in Zukunft komplexer als beim Speichern mit jedem separaten Kennwort, da Sie stattdessen einen Indikator speichern müssen, welche Iterationskonfigurationsversion für jedes Kennwort verwendet wurde. Sie könnten jedoch einen geheimen Arbeitsfaktor haben, der zu dem mit dem Hash gespeicherten Wert hinzugefügt wird.

Veracrypt hat kürzlich eine PIM-Funktion (Personal Iteration Multiplier) hinzugefügt, die als verwendet werden kann ein zusätzliches Geheimnis zum Schutz Ihrer verschlüsselten Daten.

Sie konnten einen gemeinsamen Arbeitsfaktor gegen einen Angreifer, der ein Konto für sich selbst erstellt, nicht geheim halten, bevor er Ihre Kennwortdatenbank stiehlt. Da er sein eigenes Passwort kennt, kann er es einfach hashen und sehen, wie lange es dauert, bis der Hash mit dem aus der Datenbank übereinstimmt.
Sie könnten, wenn mit einem Pfeffer kombiniert.
Daran habe ich nicht gedacht! Es wird jedoch davon ausgegangen, dass die Kennwortdatenbank mit einer öffentlichen Schnittstelle verknüpft ist.
Das beste Salz, das Sie verwenden können, sind die Informationen, die Sie hashen, da Sie als Referenz die nicht gehackte Version kennen müssen, um sie zu hashen und zu vergleichen. Wenn Sie beispielsweise ein Benutzerkennwort als Hashing Salt verwenden, ist jedes einzelne Benutzerkennwort individuell sicher. Wenn Sie es geschafft haben, es zu brutalisieren, hatten Sie bereits die Informationen zur Hand, aber wenn Sie das Benutzerpasswort als Salzquadrat verwenden, dauert es, ein einzelnes Passwort zu knacken, da Sie über das Systemsalz und das dynamische Salz verfügen.
@NKD: Die ganze Idee, Passwörter in Hash-Form zu speichern, besteht darin, den Schaden zu begrenzen, den sie verursachen würden, wenn die Passwortdatenbank in die falschen Hände geraten würde. Solange die Datenbank nicht ausläuft, gibt Ihnen Hashing nichts (ähnlich wie eine Versicherung, die Sie noch nicht benötigen).
@silverpenguin, nein, das Salz muss unterschiedlich sein, auch wenn das Passwort das gleiche ist, sonst können Angreifer sehen, dass z. Zwei Passwörter sind identisch. Es ist jedoch üblich, die Benutzer-ID in den Hash oder Salt aufzunehmen.
@HenningMakholm stimmte voll und ganz zu. Ich sagte nur, dass im Fall einer Datenbank mit Passwörtern, die in einem Unternehmen verwendet werden (z. B. Verbindungen zu einer internen Software), der Hacker kein Konto erstellen kann.
@Ben Ich verstehe Ihren Standpunkt, aber ich denke immer noch, dass das Passwort als Salt sowie möglicherweise als Benutzer-ID verwendet werden sollte ... Die Benutzer-ID / der Benutzername ist im Klartext in der Datenbank vorhanden (oder sollte es zumindest sein), wenn Sie meinen Drift erhalten Theoretisch existiert das Passwort jedoch nur im Kopf des Benutzers und in irreversibler Hash-Form
@silverpenguin, dafür ist Salz nicht gedacht. Salt muss nicht geheim sein, es muss nur für jeden Hash anders sein, es ist speziell dazu da, das Problem zu lösen, dass derselbe Klartext denselben Hash generiert, was die Tür für Regenbogentabellen- / Precompute-Angriffe oder die Entdeckung von Passwörtern öffnet zufällig das gleiche wie einander. In Ihrem Beispiel wird der Klartext (d. H. Das Kennwort) ohnehin bereits gehasht. Wenn Sie ihn also ein zweites Mal zum Hash hinzufügen, können Sie auch nichts dagegen tun. Salz soll beides. Siehe Erklärung hier: https://en.wikipedia.org/wiki/Salt_%28cryptography%29
"Es ist jedoch schwieriger, dies in Zukunft zu verbessern, als wenn es mit jedem einzelnen Passwort gespeichert wird" - nicht wirklich. Ich meine, Sie möchten jeden sofort auf die höhere Iterationszahl aktualisieren und nicht nur, wenn er sein Passwort ändert, also möchten Sie es trotzdem auf einmal tun. Am Ende ist es nicht wirklich nützlich, die Anzahl der Iterationen zu speichern, wenn Sie nur das Hash-Passwort verwenden und den Hashing-Algorithmus noch ein paar Runden anwenden. Solange der Benutzer jedoch ein eigenes Konto erstellen kann, kostet Sie dies auch nichts.
@Voo, das davon ausgeht, dass so etwas möglich ist. Wenn Ihr Passwort-Hash wirklich nur N Wiederholungen eines einfacheren Hashs ist, dann ist es vielleicht so, aber z. für bcrypt ist es nicht. Der Arbeitsfaktor steuert, wie viel Hashing durchgeführt wird, um einen Schlüssel für einen letzten Verschlüsselungsschritt zu generieren, und dann wird der Schlüssel weggeworfen. Sie können einem bcrypt-Hash nicht einfach "Runden hinzufügen", sondern müssen ihn aus dem Kennwort selbst neu berechnen.
(Sie müssen jedoch nicht warten, bis ein Benutzer sein Kennwort ändert, um seinen Hash zu aktualisieren. Sie haben auch sein Kennwort bei einer erfolgreichen Anmeldung.)
@Hobbs wusste nicht, dass Sie das mit bcrypt nicht machen können - ging davon aus, dass es PBKDF2 ähnlich sein würde. Ja, in diesem Fall benötigen Sie die zusätzliche Komplexität Ihres Anmeldevorgangs und müssen einige zusätzliche Informationen in der Datenbank speichern. Dies kann auch die Anzahl der Iterationen sein.
@Voo: Selbst mit Hashing-Schemata, mit denen Sie die Anzahl der Iterationen in der von Ihnen dargestellten Weise erhöhen können, möchten Sie die Iterationszahl jedes Hashs zusammen mit dem Hash speichern, da andernfalls für ein Update eine einzige Transaktionsaktualisierung aller Hashes erforderlich wäre * und * des Wissens der Software darüber, wie hoch die Iterationszahl sein soll. Dies bedeutet, dass Sie das Update nicht wirklich durchführen können, ohne Ihr System für den Flip offline zu schalten.
#2
+14
Robert
2015-08-29 05:09:45 UTC
view on stackexchange narkive permalink

Woher weiß ein Hacker, wie oft ein Passwort gehasht wurde? Genauso wie Sie.

Das Ziel des Hashens eines Passworts besteht darin, es unmöglich (in der Praxis sehr schwierig) zu machen, das Passwort zu bestimmen, selbst bei vollem Zugriff auf Alle Daten .

Die andere Voraussetzung für das Hashing ist, dass der Server feststellen kann, ob ein eingegebenes Kennwort korrekt ist. Dies bedeutet, dass der Server zu einem bestimmten Zeitpunkt während des Anmeldevorgangs Zugriff auf die vollständige Formel zum Hashing eines Kennworts haben muss.

Der Zweck des Variierens der Anzahl der Hashes besteht hauptsächlich darin, Brute-Force-Angriffe zu verlangsamen und zu erhöhen den Suchraum für Regenbogentabellen, und dies funktioniert ohne Geheimhaltung . Aus diesem Grund wird die Anzahl der Runden normalerweise direkt in der Datenbank mit dem Hash gespeichert, wie in der Antwort von SilverlightFox.

Es gibt Lösungen, die die Anzahl der Runden separat speichern und versuchen, sie geheim zu halten eine zusätzliche Schutzschicht. Bei der Bewertung des Hashing-Systems müssen wir jedoch davon ausgehen, dass der Angreifer alles weiß, was wir wissen .

Wenn es einen Platz zum Speichern der Anzahl der Runden gab, der garantiert nicht war Um kompromittiert zu werden, könnten wir einfach die Passwörter dort speichern und uns überhaupt nicht um Hashing kümmern.

#3
+7
Mike Scott
2015-08-28 15:10:12 UTC
view on stackexchange narkive permalink

Die Anzahl der Iterationen und das Salt werden in derselben Datenbank gespeichert, normalerweise im selben Feld wie der Kennwort-Hash. Weil die Site diese Dinge genauso gut kennen muss wie ein potenzieller Angreifer und sie daher leicht verfügbar sein müssen. Beispielsweise enthalten bcrypt -Hash-Passwörter die (Protokollbasis 2 der) Anzahl von Iterationen, die durch $ -Zeichen vom Rest des Hashs getrennt sind.

#4
+3
otus
2015-08-29 17:06:38 UTC
view on stackexchange narkive permalink

Während die aktuell akzeptierte Antwort korrekt ist und die Anzahl der Iterationen normalerweise dort gespeichert wird, wo sich die Hashes selbst befinden, auch wenn dies nicht der Fall war:

  1. Von Kerckhoffs Prinzip sollten Sie davon ausgehen, dass der Angreifer es herausfinden kann. In der Praxis könnten sie dies beispielsweise herausfinden, indem sie ihre eigene Anmeldung mit einem bekannten Kennwort erstellen oder einen Anmeldeversuch planen.

  2. Selbst wenn die Anzahl der Iterationen unbekannt wäre, wäre dies nur der Fall Fügen Sie der Zeit, die der Angreifer benötigt, um sie alle zu überprüfen, einen konstanten Faktor hinzu, zumindest mit allgemeinen Kennwort-Hashing-Funktionen wie PBKDF2, mit denen Sie den 1000-Iterations-Hash aus dem 999-Iterations-Hash mit ableiten können eine einzelne Iteration. Der Angreifer müsste nur die Zwischenwerte mit dem Kennwort-Hash vergleichen.

  3. ol>


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...