Frage:
Ist es eine schlechte Praxis, meinem Hash den verwendeten Algorithmus voranzustellen?
Mathias Lykkegaard Lorenzen
2018-11-08 19:25:07 UTC
view on stackexchange narkive permalink

Angenommen, ich habe eine Datenbank mit einer Reihe von Benutzern. Diese Benutzerdatenbank hat normalerweise ein Hash-Passwort pro Benutzer. Wäre es eine schlechte Praxis, diesem Hash den verwendeten Hashing-Algorithmus voranzustellen?

Anstelle des Hashs aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d speichere ich sha1_aaf4c61ddcc5e8a2dabede0f9b942cd Die Methode zum Erstellen des Hashs ist SHA1.

Ich habe festgestellt, dass Argon2 dies tut, und ich denke, dass dies sehr praktisch ist, da es für neuere Benutzer im Laufe der Zeit einfacher ist, teilweise auf neuere Hashing-Algorithmen zu migrieren.

Ich verwende SHA1 nicht in meinem Produktionscode für Passwörter. SHA1 wurde zufällig ausgewählt. Bei dieser Frage geht es nicht um die Verwendung der Hashing-Methode.

Kommentare sind nicht für eine ausführliche Diskussion gedacht.Diese Konversation wurde [in den Chat verschoben] (https://chat.stackexchange.com/rooms/85699/discussion-on-question-by-mathias-lykkegaard-lorenzen-is-it-bad-practice-to-pref).
Fünf antworten:
schroeder
2018-11-08 19:28:19 UTC
view on stackexchange narkive permalink

Viele verschiedene Passwort-Hashing-Systeme tun dies. Die Art des verwendeten Hashing-Mechanismus sollte kein Geheimnis sein (und sollte es auch nicht sein müssen). Kerckhoffs Prinzip lautet:

Ein Kryptosystem sollte sicher sein, auch wenn alles am System außer dem Schlüssel öffentlich bekannt ist.

Wenn Ihr System also ordnungsgemäß sicher ist, sollte es keine Rolle spielen, ob der Hash-Mechanismus verfügbar ist.

Warum "sollte nicht sein"?Sollte es nicht notwendig sein, geheim zu sein, ist Kerckhoffs Prinzip, aber solange es Sie nicht dazu bringt, Kompromisse bei der Schlüsselsicherheit einzugehen, kann es auch keinen Schaden anrichten, wenn der Hash-Algorithmus ebenfalls geheim ist.
@leftaroundabout, bei dem es um Kerckhoffs geht.Operativ und politisch gesehen ist es ein Problem, den Hashing-Algorithmus als Geheimnis zu klassifizieren.Es wird versucht, Sicherheit durch Dunkelheit zu gewährleisten, und es werden Kontrollkosten eingeführt, die die Vorteile überwiegen.Ganz zu schweigen vom praktischen Anwendungsfall von Toby Speight.Es geht nicht darum, den Alo-Typ voranzustellen, sondern um die Klassifizierung der Daten über den Algo-Typ.
Es als Geheimnis zu klassifizieren ist nicht notwendig, damit es geheim ist.Es kann übrigens aus Leistungsgründen geheim sein.
Unterschied zwischen der Geheimhaltung und der Nichtoffenlegung.In diesem Fall geht es um die Klassifizierung dieser Daten, nicht um die Nichtoffenlegung (obwohl es im Kontext um die Offenlegung geht).
Ich hatte den Eindruck, dass das Hinzufügen von "Sicherheit durch Dunkelheit" immer noch eine gute Sache ist.Systeme * sollten * sicher sein, auch wenn Sie alle Details des Systems kennen, aber das Hinzufügen von Dunkelheit erhöht die Sicherheit (um Angreifer zu verlangsamen, Systeme zu verbergen, wenn 0-Tage-Fehler gefunden werden usw.).Ist es so fair?
@NathanMerrill Ich würde sagen, dass es von Fall zu Fall genommen werden sollte.In diesem Fall überwiegt meiner Meinung nach der Vorteil, dass der Algorithmus mit dem Hash gespeichert wird, den sehr geringen Sicherheitsvorteil, den Sie erhalten würden, wenn Sie ihn verdecken.
Ich muss @leftaroundabout zustimmen.Diese Interpretation von Kerckhoff ist meiner Meinung nach ähnlich fehlerhaft wie die übliche Interpretation von Occams Rasiermesser, die besagt, dass "die einfachste Lösung immer richtig ist".Es ist nicht schlecht, ein Implementierungsdetail geheim zu halten (oder zumindest etwas undurchsichtig), solange Sie sich nicht als Sicherheitsmaßnahme darauf verlassen.Es macht das Leben eines unerfahrenen Angreifers allerdings etwas schwieriger.Viele Unternehmen haben ihre "geheime Soße" a.k.a. Geschäftsgeheimnisse durch legale Mittel geschützt (was auch dann funktioniert, wenn das Geheimnis bekannt ist), aber sie behalten ihre Geheimnisse immer noch geheim.
@Damon Nun, ich meinte, dass es nicht gut ist, Implementierungsdetails im Klartext mit einer Chiffre zu bündeln, nur um „Kerckhoffs Prinzip einzuhalten“.Das bringt Ihnen nichts, es sei denn, es hat unabhängige Vorteile (wie die Erleichterung der Migration zu einem anderen Hash, aber dafür ist es nicht die einzige und wohl ziemlich hackige Option, den Namen des Hash in ASCII voranzustellen).Das absichtliche Veröffentlichen von Implementierungsdetails ist nur dann ein Vorteil, wenn dies so erfolgt, dass Sie eine Peer-Review erhalten (Open-Source-Bibliothek usw.).Wenn nichts davon zutrifft, halten Sie es einfach und lassen Sie den Algorithmusnamen weg.
Das Prinzip von @NathanMerrill Kerkhoff wird verwendet, um Härtungssysteme zu ermöglichen.Wenn alles außer dem Schlüssel offen ist, kann es umfassend geprüft werden.Wenn Teile des Systems nicht geöffnet sind, muss jeder, der versucht, seine Sicherheit zu überprüfen, diese Teile rückentwickeln, bevor er sie ordnungsgemäß bewerten kann.
@leftaroundabout: Genau das sage ich.Veröffentlichung eines Geheimnisses wegen "weil Kerckhoff!"ist eine falsche Interpretation dieses Prinzips (meiner Meinung nach).
@Deduplicator das stimmt: Sie möchten, dass es für Angreifer und nicht für Bewerter undurchsichtig ist.Es gibt definitiv Szenarien, in denen dies nicht möglich ist.
Anders
2018-11-08 19:41:49 UTC
view on stackexchange narkive permalink

Ich stimme schroeder zu, dass dies in Ordnung ist. Auch ohne Präfix kann ein Angreifer wahrscheinlich herausfinden, welchen Algorithmus Sie verwenden. Auf jeden Fall ist es die Stärke des Hashing-Algorithmus, die die Passwörter schützt, nicht die Geheimhaltung des Algorithmus.

Beachten Sie, dass viele Hashing-Algorithmen und -Bibliotheken dies bereits für Sie tun. Sie binden alle relevanten Informationen - Algorithmus, Kostenfaktoren, Salz, der eigentliche Hash - in eine serialisierte Zeichenfolge ein. Siehe zum Beispiel das Modular Crypt Format oder die PHP password_hash -Funktion. Also mach dir kein eigenes Schema. Wenn Sie eine Abstiegs-Hashing-Bibliothek verwenden, haben Sie bereits eine.

Verwenden Sie SHA1 jedoch nicht zum Hashing von Passwörtern. Das ist nicht in Ordnung.

Ja, ich habe SHA1 verwendet, weil der Hash von "Hallo" für ein Beispiel in SHA512 zu lang war.
@MathiasLykkegaardLorenzen Verwenden Sie SHA512 auch nicht, es sei denn, es ist nur eine Komponente in einem größeren Schema mit mehr Iterationen.Aber natürlich geht zum Beispiel alles!:-)
@MathiasLykkegaardLorenzen Und verwenden Sie nicht nur mehrere Iterationen!Verwenden Sie ein bewährtes Konstrukt wie PBKDF2, das HMAC verwendet (nicht nur rohe Hash-Iterationen).
Wird SHA512 als unsicher angesehen?Das wusste ich damals noch nicht.Können Sie auf einen Artikel verweisen, in dem angegeben wird, warum?
Es ist nicht unsicher für das, wofür es entwickelt wurde (d. H. Hashing-Daten), aber es wurde entwickelt, um * schnell * zu sein.Sie möchten, dass Ihre Passwort-Hash-Funktion langsam ist, um Brute-Force-Versuche abzuwehren.
Aber selbst wenn es schnell ist, spielt es eine Rolle, ob die Anzahl der Versuche, die erforderlich wären (wenn Salz und Pfeffer hinzugefügt werden), immer noch wahnsinnig hoch ist?
Ja, es ist immer noch wichtig.Hashing-Funktionen sind aufgrund ihrer Geschwindigkeit nicht für die Speicherung von Passwörtern gedacht.Mit einer einzelnen p3.16xlarge-Instanz bei Amazon können Sie mit SHA512 17,28 Milliarden Vermutungen pro Sekunde anstellen.Das bedeutet, dass Sie jedes 8-stellige Passwort für Buchstaben und Zahlen in nur 151,17 Sekunden knacken können.Schlüsselableitungsfunktionen dienen zum Speichern von Passwörtern, da diese langsam sind.Mit bcrypt auf Workfaktor 12 können Sie nur 424200 Vermutungen pro Sekunde anstellen.Das würde pro Passwort 34,8 Tage dauern.Zusätzlich haben bcrypt und argon2 Salze eingebaut, sodass Sie sich keine Gedanken über das Versalzen der Passwörter machen müssen.
Toby Speight
2018-11-08 21:59:44 UTC
view on stackexchange narkive permalink

Nein, es ist keine schlechte Praxis, und Sie sollten diese Informationen wohl behalten .

Wie Sie beobachten, können Sie den Algorithmus für neue Passwörter jederzeit ändern. ohne die vorhandenen Passwörter aller Benutzer ungültig zu machen (dies führt dazu, dass Sie aus irgendeinem Grund unbeliebt werden).

Es gibt ein Argument, dass ein Angreifer die älteren, schwächeren Passwörter suchen kann, um zuerst anzugreifen, aber Sie haben ihre Sicherheit überhaupt nicht reduziert (unter der Annahme von Kerckhoffs Prinzip, dass der Algorithmus selbst kein Geheimnis sein muss).

Wenn eine Kombination aus Algorithmen und Salzen gespeichert werden kann, müssen schwächere Passwörter nicht beibehalten werden, sobald stärkere Algorithmen verfügbar sind.Wenn der aktuelle Eintrag besagt, dass das Durchlaufen des Kennworts durch einen schwachen Algorithmus mit salt1 X ergibt, berechnen Sie einfach Y, indem Sie X durch einen stärkeren Algorithmus mit salt2 führen. Ändern Sie dann den Eintrag so, dass das Kennwort durch den schwachen Algorithmus mit salt1 gestellt wird, und geben Sie dann das Ergebnis von * eindass * durch einen stärkeren Algorithmus mit salt2 Y ergibt. Sie müssen nicht warten, bis sich der Benutzer anmeldet.
leo v
2018-11-09 01:27:51 UTC
view on stackexchange narkive permalink

Es wird empfohlen, den Hashing-Algorithmus zu speichern, aber ordnungsgemäße Kennwort-Hashing-Funktionen wie Argon2 und PBKDF2 kümmern sich bereits darum. Es ist jedoch eine schlechte Praxis, SHA1 oder SHA256 allein für das Hashing von Passwörtern zu verwenden, da es sich um einen festen (und relativ geringen) Arbeitsaufwand handelt, der mithilfe von Wörterbuchangriffen und Brute Force geknackt werden muss. Diese Passwörter sollten zu einer sicheren Hashing-Funktion migriert werden, indem das Passwort bei der nächsten Anmeldung erneut aufbereitet wird. Weitere Informationen finden Sie unter https://crypto.stackexchange.com/a/45405.

Nicolas Marshall
2018-11-10 00:11:22 UTC
view on stackexchange narkive permalink

Es ist keine schlechte Praxis, es ist eigentlich eine übliche Sache. Wenn Sie die Datei / etc / shadow auf einem Linux-Computer öffnen, wird Ihrem Hash-Passwort $ x $ salt $ vorangestellt, wobei x eine Zahl ist, die angibt, welcher Hash-Algorithmus verwendet wurde. P. >

Nun einige Dinge zu beachten:

  • Verwenden Sie SHA1 nicht direkt als Hashing-Algorithmus. Verwenden Sie stattdessen bcrypt, scrypt oder argon2 (was Sie erwähnt haben, aber dies kann nicht zu oft wiederholt werden). Diese verwenden zwar einen einfachen Hashing-Algorithmus wie SHA1 als Basis, führen ihn jedoch auf eine spezielle Weise aus, die ihn gegen Angriffe resistent macht.
  • aus praktischen Gründen, da Sie eine Datenbank und keine Datei verwenden. Möglicherweise möchten Sie die Hashing-Methode und Salt in separaten Zeilen speichern. Sie können die Zeichenfolge jedoch auch beginnend mit $ x $ salt $ in Ihrer Datenbank speichern und die Salt- und Hashing-Methode aus dieser Zeichenfolge analysieren, wenn Sie das Kennwort überprüfen. Es ist wahrscheinlich schnell genug, dass es keinen signifikanten Unterschied macht. In beiden Fällen ist die Sicherheit Ihres Systems gleich.
Das OP sagt in Kommentaren, dass SHA-1 nur als Beispiel verwendet wurde und nicht in der Produktion verwendet wird
Man muss mehr als "so oft ausführen" verwenden, es muss eine CPU-Auslastung oder ~ 100 ms und ein zufälliges Salz haben.
@schroeder Ich war mir beim Lesen der Frage nicht so sicher.
@zaph stimme absolut zu, aber ich wollte nicht auf Einzelheiten eingehen.Ich habe meine Antwort bearbeitet, um sie weniger mehrdeutig zu machen


ⓘ
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 4.0-Lizenz, unter der er vertrieben wird.
Loading...