Ist es okay, zu speichern Salze mit hashes?

Mein Verständnis ist, dass ein Salz ist bestimmt nicht geheim, es ist lediglich dazu gedacht, anders zu sein als in einem zentralisierten standard, so dass Sie nicht entwickeln eine rainbow-Tabelle oder ähnlichen Angriffs zu brechen, alle hashes, die den Algorithmus verwenden, da das Salz bricht die rainbow-table. Mein Verständnis hier vielleicht nicht ganz richtig ist, also korrigiert mich wenn ich falsch Liege.

In eine weit verbreitete Stück open-source-software, das Salz wäre allgemein bekannt, und dieses öffnet Sie, um Angriffe denn nun können Sie einfach angreifen, die gesalzene version Ihres hash-und rainbow-Tabellen erstellen, die auch die Salz-Daten.

Wie ich es sehe, gibt es zwei Möglichkeiten, damit umzugehen. Die erste ist die Veränderung des Salzes sich mit jeder neuen version der software, aber das ist nicht gut, weil neue Versionen der software würde nicht mehr in der Lage sein, um test gegen alte Passwort-hashes.

Die zweite Lösung, die ich dachte, war eine salt pro Passwort gespeichert werden; in anderen Worten, jedes Passwort bekommt einen anderen Salz. Der Nachteil ist, dass die Salze haben, die im Zusammenhang mit der Passwort-hashes in irgendeiner Weise, die wahrscheinlich nur durch kleben Sie Sie rechts neben dem Passwort in der Datenbank. Es ist auch in Ordnung, verwenden Sie den Benutzernamen (es vielleicht nicht, aber wahrscheinlich Benutzernamen sind zu kurz).

Meine Frage ist, ist dies akzeptabel? Gibt es zusätzliche Risiken in Verbindung mit der Speicherung das Salz direkt mit der Passwort-hashes? Es scheint mir, dass das speichern das Salz in der source-code ist nicht anders, so gibt es keine Sicherheits-Verlust durch Lagerung des Salzes mit dem Passwort.

DISCLAIMER: ich bin nicht mit dieser für real-life-Sicherheit-system. In der Tat, ich habe nie entwickelt, ein Passwort-system jeglicher Art. Ich bin nur halten mich vage, bei der Aufklärungsarbeit zu Sicherheitsthemen.

  • Es war ein toller Artikel diskutieren heute, sagte, dass, HMAC.
  • Gibt es einen Grund, Salz + HMAC wäre unwirksam?
  • +1 und wenn ich könnte, ich würde Euch gegeben haben, eine weitere Stimme einfach für deinen avatar 🙂
  • Beachten Sie, dass dieser Artikel ist nicht über das speichern Kennwort. Es ist über den ursprünglichen Zweck der HMAC Authentifizierung von Nachrichten (signieren von Nachrichten). Aber natürlich HMAC ist eine gute Wahl für die Speicherung gesalzene Passwörter, zu.
  • Aber nur um klar zu sein für Imagist, das Salz würde ein Teil der Eingabe für die HMAC-Funktion, so HMAC bedeutet nicht, das Salz ist das nicht sinnvoll.
  • Was über Salze erzeugt von account-Informationen wie den Benutzernamen oder sogar ein Salz-basierend auf dem Passwort? Mir scheint, dies würde garantieren einzigartige Salze, und würde bedeuten, einen möglichen Angreifer müssten sowohl Ihre Datenbank und den Quell-code herauszufinden, der Salz verwendet.
  • Eine Verwandte Frage: stackoverflow.com/questions/1479234/...
  • Eine andere Frage im Zusammenhang: stackoverflow.com/questions/1645161/...
  • B Off-topic ein bisschen, aber ich bin ein riesiger Domo-Enthusiasten.

InformationsquelleAutor Imagist | 2009-10-30
  1. 19

    update: verwenden Sie ein kompetenter Bibliothek z.B. passlib für Python.

    Diese kümmern sich um die Generierung einer pro-Kennwort Salz und verwenden Sie eine richtige hashing-Algorithmus (dessen nicht genug, nur verwenden einer kryptographischen hash-wie SHA1; Sie haben, um es zu übernehmen in einer Weise, die macht es sehr langsam, um reverse-z.B. looping 1000 oder mehr mal über es, etc.. Dies ist, wie Passwort-hash-Funktionen wie bcrypt Arbeit. Kennwort speichern-Bibliotheken tun dies alles richtig; Sie verursachen in der Regel eine Zeichenfolge, Trennzeichen, so dass Sie bestimmen können, welche hash-system und arbeiten-Faktor, die Sie gerade speichern Sie die Zeichenfolge ohne dies zu wissen.

    Können Sie speichern das Salz in 'plain-text' in der Tabelle.

    • Salt muss nicht geheim sein, um wirksam zu sein

    • es muss nur zufällig sein.

    Das Salz stärkt Sie ein Kennwort, indem Sie den Hash-Wert vergleichen, den dasselbe Kennwort in der gleichen oder einer anderen Datenbank, und ungültig großen pre-generierte Listen von gemeinsamen Kennwort-hash-lookups (z.B. "rainbow tables").

    Deshalb ist es wichtig, dass das Salz ist einmalig pro Kunde und ist einige zufällige Wert gespeichert, mit dem Kennwort, die alternativen beschrieben in der Frage (mit dem Benutzernamen, als das Salz über einen salt-Wert für die gesamte Anwendung) jedes scheitern:

    • wenn Systeme verwenden Sie den Benutzer-Namen oder andere Kleinigkeiten, dann das Passwort können Sie im Vergleich zu anderen Benutzern mit dem gleichen Namen, die in anderen Systemen (sich vorstellen, wie oft der Benutzer "administrator" oder "root" - Benutzerkonto verwendet das gleiche Passwort in verschiedenen Systemen...)

    • wenn das system verwendet einen einzelnen zufälligen salt für alle Benutzer in dem selben system, dann zwei Benutzer, die durch Zufall das gleiche Passwort hätte den gleichen hash, und raten zu einem Benutzer-Passworts trivial Kompromisse das andere.

    • Wie ich bereits in meinen anderen Kommentaren, müssen Sie einen einzigartigen Salz pro hash. Ich kann nicht sehen keinen nutzen in die es zufällig? In Bezug auf deinen ersten Punkt ", wenn Systeme verwenden Sie den Benutzer-Namen oder andere Kleinigkeiten..." - wenn ein eindeutiger hash pro Benutzer verwendet wird (z.B. primary key oder Benutzernamen), dann ist dies kein Problem.
    • pro-user"=="einzigartigen Salz pro hash". Und Sie fordern, können Sie den Benutzernamen nicht die erste fail-Punkt oben, wie gezeigt in meinem Beispiel.
    • Fairer Punkt 🙂 Michael Borgwardt schlug vor, auch mit etwas einzigartigen, um das system - wenn Sie verkettet, dass die einzigartige pro-Benutzer-hash, die Sie erhalten rund um das Thema.
    • dann sind Sie nur schieben das problem in die dunkle Ecke bei was passiert, wenn ein Benutzer entfernt wird, wird dann neu erstellt. Es ist eine kleine dunkle Ecke, aber sein dort. Gehen Sie einfach mit einem zufälligen gespeicherten Wert in der Passwort-Datenbank mit dem Passwort-hash und mit ihm getan werden! Sein, wie die Fachleute, die gelesen haben Bruce es tun 😉
    • OK, ich gebe zu - es scheint, gibt es Vorteile der Verwendung von einem zufälligen salt und speichern, anstatt mit vorhandenen Daten.
    InformationsquelleAutor Will
  2. 9

    Versucht zu halten, den salt secret ist sinnlos, weil die gesamte Praxis von Salzen und Hashen der Passwörter existiert nur, weil wir aus Erfahrung wissen, dass wir nicht halten unsere Datenbanken geheim mit absoluter Zuverlässigkeit. Sie können bei den meisten speichern das Salz separat und hoffen, dass ein Angreifer, der bekommt Zugriff auf Ihre DB nicht finden, aber wenn Sie ein guter Hash-Algorithmus und lange genug die einzelnen Salze, Sie sollten sicher sein, so oder so.

    Der Punkt, der ein Salz ist allein, um sicherzustellen, dass Sie nicht amortisieren, die Kosten für eine brute-force-Angriff auf eine ganze Datenbank oder sogar mehreren Datenbanken.

    Die erste ist, zu ändern, das Salz mit
    jede neue version der software, aber
    das ist nicht gut, weil neue Versionen
    von der software würde nicht mehr werden
    testen konnte gegen alte Passwort
    hashes.

    Einer variation davon, die ich gesehen habe, ist zum generieren einer zufälligen salt während der installation (und natürlich halten diese in verschiedenen Versionen), so dass jede ausgeführte Instanz hat eine andere. Natürlich, mit einem anderen salt für jedes Passwort (vielleicht zusätzlich zu der vorstehend) ist noch besser.

    • +1: "der Punkt, Der ein Salz ist allein, um sicherzustellen, dass Sie nicht amortisieren, die Kosten für eine brute-force-Angriff auf eine ganze Datenbank oder sogar mehreren Datenbanken." Sehr bündig.
    InformationsquelleAutor Michael Borgwardt
  3. 1

    Den Salz, per definition, muss zufällig sein, um wirksam zu sein. Verwenden Sie keine deterministischen Wert für diese. Dies impliziert freilich, dass Sie brauchen, um es zu speichern in der Datenbank zusammen mit dem Hash-Passwort. UNIX-Systeme traditionell sogar speichern den hash, der in dem gleichen Gebiet wie das Kennwort ein (das Salz ist ein fester Länge-Präfix Passwort). In einer Datenbank haben, können Sie die zusätzliche Spalte in der Tabelle users.

    • Dies ist nicht korrekt. Der Hauptzweck von Salzen ist zu besiegen mit vordefinierten hash-Tabellen (aka rainbow-Tabellen). Jeder hash-Salz sollte einmalig sein, aber müssen nicht zufällig sein. Ich empfehle Bruce Schneier ' s Buch Angewandte Kryptographie: schneier.com/book-applied.html
    • Wikipedia ist nicht Die Definitive Quelle. Es gibt nicht wirklich einen zusätzlichen nutzen erhalten Sie von zufälligen Salze über, die einfach einzigartig lieben.
    • Das Salz muss sich nicht unbedingt zufällig zu sein, streng genommen, aber es hat eine hohe Entropie. Wenn Salze sind ähnlich (Sie "cluster"), dann werden Sie nicht viel Wert. Ein PRNG ist ein einfacher Weg, um die Entropie, aber es gibt andere Wege.
    • Ich glaube nicht, dass es wichtig ist, wenn die "cluster", wie Sie noch eindeutig sein für jeden hash - und deshalb vorgefertigte Tabellen können nicht verwendet werden.
    • +1 Lukas. @Cocowalla der Wert das Salz sollte nicht bestimmt werden von nichts anderen zwei Systemen bestimmen Sie auf die gleiche Weise... siehe meine Antwort, und betrachten Sie 'zufällig' in diesem Kontext.
    • Es ist vage möglich, dass Salze ausstellen Regelmäßigkeit könnte ermöglichen Angreifern Schwachstellen im Hash-Algorithmus, ist aber extrem unwahrscheinlich. Wenn Sie besorgt über diese, Ihre Zeit wäre besser ausgegeben werden Suche nach einem hashing-Algorithmus, der ohne solche Schwächen.
    • guter Punkt; obwohl ein deterministisch Salz, der garantiert, dass (oder sehr wahrscheinlich) zu unterscheiden zwischen Systemen, wie den domain-Namen, würde verhindern, dass diese als gut.
    • Ich muss sagen, dass ich nicht wirklich diese Diskussion. Mit eine einzigartige random-Salz ist derzeit die beste option, die Sie tun können. Wir können argumentieren, wie nicht notwendig, aber wenn Sie die beste option ist auch die einfachste Möglichkeit, warum Sie einfach nicht nutzen? Erzeugung einer zufälligen Zahl ist viel schwieriger zu versauen als die Suche nach einem guten genug, key in Ihren vorhandenen Daten.
    • Bedenken Sie, dass, wenn Sie erzeugen eine zufällige Salz müssen Sie in der Lage sein, um es neu erstellen, Wann immer Sie brauchen, um zu überprüfen, anhand der gespeicherten hash. So, das Salz muss entweder irgendwo gespeichert oder ableitbar. Ich denke, die einfachste Möglichkeit ist die Verwendung von vorhandenen, eindeutigen Daten.
    • Speichern der Zufallszahl, die in Ihrer Datenbank ist auf jeden Fall einfacher als die Bestimmung, was gut ist, bereits vorhandene Daten zu verwenden. Sie nicht brauchen, um darüber nachzudenken, es nicht einschränken, Sie verändern die bestehenden Daten in die Zukunft, es ist eine komplett eigenständige Lösung, die einfach funktioniert. Wenn Sie müssen, ändern Sie die vorhandenen Daten verwendet, für Salze aus irgendeinem Grund (und alles braucht schließlich ändern), können Sie nicht nur sofort wieder die Passwörter.
    • Sie können ein Pferd zum Wasser führen aber man kann ihn nicht zwingen zu trinken
    • "Wenn die beste Möglichkeit ist auch die einfachste Möglichkeit, warum Sie einfach nicht nutzen?" - verdammt, wenn das nicht ein feines Zitat. Es wird auf meiner Liste.

    InformationsquelleAutor Lukáš Lalinský
  4. 0

    Ist es völlig normal, zu erzeugen, einem einzigartigen salt für jedes Passwort. Das Salz kann ein Produkt von vorhandenen material (wie beispielsweise eine Benutzer-id, et al.) oder zufällig generiert werden. Der Vorteil ist, dass ein Angriff gegen die verschlüsselten Informationen wird mehr unpraktisch als die Kraft des Salzes wächst.

    Denken Sie daran: Jeder kryptografische Algorithmus ist zerbrechlich. Informationen können nur dann berücksichtigt werden, "sicher", wenn das knacken der Schutz (per rainbow-table oder anderweitig) ist teurer als die information Wert ist.

    edit:

    Vorausgesetzt, Sie sind sehr neu in die Kryptographie, hier ein paar weitere Tipps:

    • Mehr Salze sind besser als kurze.
    • Die mehr möglichen Werten für ein Salz ist, desto besser. Eine alpha-numerische Salz ist besser als ein numerisch eines. Ein binäres Salz ist besser als eine alpha-numerische eins.
    • Salze nicht machen brute-force - Attacken weniger wahrscheinlich gegen ein einzelnes Passwort.
    • Es ist nicht nur völlig normal für Salze eindeutig pro-Passwort - das ist so ziemlich die definition, was ein Salz ist. Wenn das Salz ist nicht für jedes Kennwort, das ziemlich Niederlagen der Zweck des Salzes.
    • Ist es nicht die Niederlage der Zweck völlig - mit den gleichen salt für die gesamte Datenbank ist noch viel, viel besser als mit gar keiner, denn es gibt zwar vorausberechneten rainbow tables für ungesalzene MD5 und SHA1, es wird nicht für einen ausreichend langen salt. Und Datenverarbeitung, eigene rainbow-Tabelle ist nicht möglich (oder zumindest zu teuer, zu stören), die für die meisten Angreifer.
    • Borgwardt: stimmt, aber noch besser ist es, eine eindeutige salt pro Passwort. Dies ist trivial zu tun, so gibt es wenig Grund, es nicht zu tun.
    InformationsquelleAutor Jesse Hallam
  5. 0

    Deine zweite Lösung "Haben eine salt pro Passwort gespeichert" die richtige ist, und in der Regel verwendet.

    Dem "Salz" ist in Erster Linie da, um es schwierig zu erkennen, wenn zwei Benutzer das gleiche Kennwort haben - so mischen Sie einen bekannten "Salz" in das Passwort. Das Salz muss sein get erreichbar password check Zeit.

    In der Regel also entweder man generiert einen zufälligen salt und speichern Sie es mit dem Passwort, ODER Sie verwenden eine andere Kennung (Benutzer-ID, Benutzername etc) als das Salz.

    • "Das "Salz" ist in Erster Linie da, um"... ich würde dies ein Nebeneffekt des Salzes. Das Prinzip der Nutzung für die Verringerung der Wahrscheinlichkeit eines erfolgreichen Angriffs.
    InformationsquelleAutor MarkR
  6. 0

    Mit einem einzigen salt für alle Passwörter in der Datenbank ist hilfreich, aber viel weniger sicher ist, als was Sie jedem Benutzer eine eindeutige Salz.

    Grundsätzlich: eine längere (in bytes) password+Salz erhöht den Suchraum, und so macht es schwieriger zu bedienen "- Aktien-standard" rainbow-Tabellen.

    Jedoch, wenn Sie ebenfalls den gleichen salt verwendet für alle Einträge, dann ist es möglich, das erstellen einer rainbow-table - speziell Angriff Ihrer software. Wenn Ihr die userbase groß ist, dann könnte jemand entscheiden, um so eine Regenbogen-Tabelle.

    Zum Beispiel, wenn Sie fügen Sie einfach "und eine Menge von Salz" am Ende jedes Passwort vor dem hashing kann ein Angreifer konstruieren Sie eine Tabelle der hash-Werte generiert, die von vielen Streichern, alle diese Zeichenfolgen mit der Endung "und eine Menge von Salz".

    Deshalb ist es für pro-Benutzer-Salz ist der beste Weg zu gehen. Beachten Sie jedoch, dass Sie möchten, dass das Kennwort+salt zu "lange".

    Wenn Sie möchten, verwenden Sie die primary key, ist es wahrscheinlich eine gute Idee, um die hash der primäre Schlüssel statt mit dem primären Schlüssel selbst, weil wenn das Passwort+salt für Benutzer 43 sieht aus wie "myPassword00000000043" dann könnte ein Angreifer eine Tabelle erstellen, mit der Annahme, dass es eine Menge Nullen in der Mitte. Erstellung von Zeitstempeln, und die zufällige Zeichenfolge, die sind wohl bessere Möglichkeiten, obwohl, wie PKeys kann manchmal leicht zu finden oder zu erraten.

    Hinweis: ich bin keine echte Verschlüsselung-Experte, verwenden Sie nicht diese Beratung in einem realen system.

    InformationsquelleAutor Artelius
  7. -1

    Du eigentlich schon haben Sie einen salt-Wert, gespeichert in der user-Tabelle: der Primärschlüssel der Tabelle.

    Müssen Sie nicht erfinden eine neue Spalte für die Speicherung von Salz. Verwenden Sie einfach die pkey. Diese Idee, die natürlich voraussetzt, dass Sie wirklich eine pkey Zusammenhang mit einem user-Namen. z.B. der Benutzername ist nicht der Primärschlüssel in der Tabelle.

    Dies ist ein in der Nähe dup wtb: Passwort-hashing, salt und Speicherung von Hash-Werten

    • Als Lukáš Lalinský sagt (stackoverflow.com/questions/1648464/...), das Salz sollte wirklich Zufall sein.
    • Oder Sie könnten einige UNIX-timestamp, wenn der Benutzer erstellt wurde oder etwas anderes. (weil es mehr als pkey)
    • aber wie ich schon erwähnt in meinem Kommentar zu Lalinský Antwort, das ist nicht korrekt - Salz gibt es nicht brauchen, um zufällig zu sein, nur einzigartig für jeden hash
    • eine entspannte interpretation des Wortes zufällig, geeignet für psasik 's und Lukas' Antworten, ist, dass zufällige Mittel, die nicht ableitbar von den anderen Daten in der Zeile.
    • wieder, ich glaube nicht, dass diese Angelegenheiten. Die Zeit, die zum erstellen von rainbow tables ist riesig (ausprobieren!), also alles, was Sie brauchen, ist ein einzigartiges Salz pro hash.
    • Wie können Sie schlagen die Leute Lesen, Bruce, und dann nicht verstehen, wie nützlich Rissbildung root:EF45DC23E100CD25 Wann tritt es auf fünf Systemen haben Sie Zugriff auf ist?
    • Ein Gültiger Punkt, den ich vergessen hatte zu berücksichtigen 🙂 Michael Borgwardt ist vorgeschlagen, auch mit etwas einzigartigen, um das system behebt das Problem. Ich noch empfehlen, Lesen, Angewandte Kryptographie, es ist nur früh am morgen und es ist schon einige Jahre her seit ich es gelesen 😉
    • Sie gehen davon aus, gerade die Verwendung eines int-pkey. Das ist nicht ein gutes Salz. Eine GUID ist eine große Salz-und ein int kann verwendet werden als ein "guter" Salz-von einigen Ableitung wie hashing oder durch einen Multiplikator Gleichung, dass die Zahl größer.
    • GUIDs enthalten eine zufällig generierte element. Ausbau etwas mehr bits, die von der Vermischung nicht, auf der anderen Seite, machen es zu einem gut Sortieren. Wenn es 4 Milliarden möglichen Eingabewerte (z.B. 32 bit) gibt es nur noch 4 Milliarden hashes abgeleitet, auch wenn Sie 100000000 bit oder mehr.
    • vereinbart. Ausbau eines int ist eher eine Verschleierung.

    InformationsquelleAutor Paul Sasik
Schreibe einen Kommentar