Salzgenerierung und Open-Source-Software

Als ich verstehen es, die besten Praktiken für die Erzeugung von Salzen ist die Nutzung von einigen kryptischen Formel (oder auch magic-Konstante) gespeichert in deinem source-code.

Arbeite ich an einem Projekt, das wir planen über die Freigabe als open source, aber das problem ist, dass mit der Quelle kommt, die geheime Formel für die Erzeugung von Salzen, und daher die Fähigkeit zum ausführen von rainbow-table-Angriffe auf unsere Website.

Ich vermute, dass viele Leute nachgedacht haben, dieses problem vor mir, und ich Frage mich, was die beste Praxis ist. Es scheint mir, dass es sinnlos ist, mit einem Salz, wenn der code open source ist, da Salze können leicht zurückentwickelt.

Gedanken?

InformationsquelleAutor der Frage user199085 | 2009-10-29

  1. 18

    Wirklich Salze müssen nur eindeutig sein für jeden Eintrag. Selbst wenn der Angreifer berechnen kann, was das Salz ist, macht es die rainbow-table-extrem schwierig zu erstellen. Dies ist, weil das Salz zum Passwort Hinzugefügt wird, bevor es gehasht ist, so ist es effektiv, fügt die Gesamtzahl der Einträge in der rainbow table enthalten muss, um eine Liste aller möglichen Werte für ein Passwort-Feld.

    InformationsquelleAutor der Antwort kemiller2002

  2. 218

    Da Fragen über das Salzen hashes begleiten Sie uns auf einer ziemlich regelmäßigen basis, und es scheint einige Verwirrung über das Thema, erweiterte ich diese Antwort.

    Was ist ein Salz?

    Salz ist ein random Satz von bytes, die eine Feste Länge, die Hinzugefügt, um die Eingabe für den hash-Algorithmus.

    Warum ist das Salzen (oder seeding) eine hash-sinnvoll?

    Hinzufügen eines zufälligen Salz zu einem hash sorgt dafür, dass das gleiche Passwort wird produzieren viele unterschiedliche hashes. Das Salz ist in der Regel in der Datenbank gespeichert, zusammen mit dem Ergebnis der hash-Funktion.
    Salzen ein hash ist gut für eine Reihe von Gründen:

    1. Salzen stark erhöht die Schwierigkeit/Kosten der precomputated Angriffe (einschließlich Regenbogen-Tabellen)
    2. Salzen stellt sicher, dass das gleiche Passwort führt nicht zu den gleichen hash.
      Dies stellt sicher, dass Sie nicht bestimmen kann, ob zwei Benutzer das gleiche Kennwort. Und noch wichtiger, können Sie nicht bestimmen, ob die gleiche person verwendet das gleiche Passwort auf unterschiedlichen Systemen.
    3. das Salzen erhöht die Komplexität der Passwörter und damit zur deutlichen Verringerung der Wirksamkeit der beiden Dictionary- und Geburtstag Angriffe. (Dies ist nur true, wenn das Salz ist gespeichert, getrennt von den hash).
    4. Richtige Salzen stark erhöht den storage-Bedarf für precomputation Angriffe, bis zu dem Punkt, wo Sie nicht mehr praktisch. (8 Zeichen, groß-und Kleinschreibung alpha-numerische Passwörter mit 16-bit-salt, Hash, um eine 128-bit-Wert, in Anspruch nehmen würde, knapp 200 Exabyte ohne Regenbogen-Reduktion).

    Es gibt keine Notwendigkeit, das Salz, verschwiegen zu sein.

    Salz ist nicht der Schlüssel, sondern ein Salz 'arbeitet', indem die hash-Funktion zu dem jeweiligen Beispiel. Mit gesalzenen hash, es ist nicht eine hash-Funktion, sondern für jeden möglichen salt-Wert. Diese verhindern, dass die Angreifer von einem Angriff N Hash-Passwörter für weniger als N mal die Kosten für einen Angriff auf ein Passwort. Dies ist der Punkt, von dem Salz.

    Eine "geheime Salz" ist ein Salz, es ist ein "Schlüssel", und es bedeutet, dass Sie nicht mehr die Berechnung einer hash, sondern eine Message Authentication Code (MAC). Computing MAC ist tricky business (viel kniffliger, als einfach-slapping-gemeinsam einen Schlüssel und einen Wert in eine hash-Funktion) und es ist ein ganz anderes Thema ganz.

    Salz muss zufällig sein für jede Instanz, in dem es verwendet wird. Dadurch wird sichergestellt, dass ein Angreifer muß jeden Angriff salted hash separat.

    Wenn Sie verlassen sich auf Ihr Salz (oder salting-Algorithmus) sein Geheimnis, geben Sie die Bereiche der Security Through Obscurity (wird nicht funktionieren). Wahrscheinlich werden Sie nicht bekommen, zusätzliche Sicherheiten vom Salz Geheimhaltung; Sie bekommen nur das warme fuzzy-Gefühl von Sicherheit. Also anstatt Ihr system sicherer, es ist nur lenkt Sie von der Realität.

    Also, warum das Salz, um zufällig zu sein?

    Technisch, das Salz sollte einzigartige. Der Punkt, der das Salz ist, Verschieden zu sein für jede Hash-Passwort. Dies soll weltweit. Da es keine zentrale Organisation, die verteilt eindeutige Salze auf die Nachfrage, wir haben verlassen, auf die nächste beste Sache, die zufällige Auswahl mit unvorhersehbarem Zufallsgenerator, vorzugsweise in einem Salz-Raum groß genug, um Kollisionen unwahrscheinlich (zwei Instanzen mit dem gleichen salt-Wert).

    Ist es verlockend, zu versuchen, abzuleiten, ein Salz von Daten, die ist "wahrscheinlich einzigartig", wie Sie die Benutzer-ID, aber solche Programme sind oft Fehler, da einige böse details:

    1. Wenn Sie zum Beispiel die Benutzer-IDeinige schlechte Jungs, Angriff auf verschiedene Systeme, kann nur Ihre Ressourcen bündeln und erstellen von vordefinierten Tabellen für die Benutzer-IDs 1 bis 50. Eine Benutzer-ID eindeutig ist system-wide aber nicht weltweit.

    2. Das gleiche gilt für die Benutzername: es ist ein "root" pro-Unix-system, aber es gibt viele Wurzeln in der Welt. Eine rainbow-Tabelle für "root" wäre der Mühe Wert, da es angewendet werden könnte, um Millionen von Systemen. Schlimmer noch, es gibt auch viele "bob" gibt, und viele haben keine sysadmin-Weiterbildung: Ihre Passwörter werden konnte, ziemlich schwach.

    3. Einzigartigkeit ist auch in zeitlicher Hinsicht. Manchmal, die Benutzer Ihr Kennwort ändern können. Für jede neues Passwortein neue Salz muss ausgewählt werden. Ansonsten ein Angreifer erlangt die hash das alte Passwort und den hash der neue könnte versuchen, Angriff beide gleichzeitig.

    Unter Verwendung eines Zufalls-Salz, gewonnen aus einer kryptografisch sicheren, unberechenbar PRNG kann eine Art overkill, aber zumindest ist es nachweislich schützt Sie gegen all diese Gefahren. Es geht nicht um die Verhinderung der Angreifer aus zu wissen, was ein einzelnen Salz ist, es geht darum, nicht die grossen, Fetten Ziel, das verwendet wird, auf eine beträchtliche Anzahl von potentiellen Zielen. Zufällige Auswahl macht die Ziele so Dünn wie möglich ist.

    In der Zusammenfassung:

    Verwenden Sie eine zufällige, gleichmäßig verteilte, hohe Entropie Salz. Verwenden Sie ein neues Salz, Wann immer Sie ein neues Passwort erstellen oder ändern Sie ein Passwort. Lagern Sie das Salz zusammen mit dem Hash-Passwort. Gefallen groß Salze (mindestens 10 bytes, vorzugsweise 16 oder mehr).

    Salz lässt sich nicht einschalten, ein schlechtes Passwort zu einem guten Passwort. Es macht einfach sicher, dass der Angreifer zumindest bezahlen die Wörterbuch-Angriff Preis für jeder schlechtes Passwort, das er bricht.


    Nützliche Quellen:

    stackoverflow.com: Nicht-zufälligen salt für Passwort-hashes

    Bruce Schneier: " Practical Cryptography (Buch)

    Matasano Security: Genug mit den Rainbow-Tabellen

    usenix.org: Unix-crypt verwendet Salz seit 1976

    owasp.org: Warum Salz

    openwall.com: Salze

    Haftungsausschluss:

    Ich bin kein security-Experte. (Obwohl diese Antwort wurde überprüft, indem Thomas Pornin)

    Wenn einer von den security-Experten da draußen etwas finden, was falsch ist, bitte kommentieren oder Bearbeiten dieser wiki-Antwort.

    InformationsquelleAutor der Antwort

  3. 7

    Da Unix populär wurde, der richtige Weg, ein Passwort zu speichern, wurde für das Anhängen eines zufälligen Wert (salt) und hash. Speichern Sie das Salz Weg, wo Sie bekommen können, um es später, aber wo Sie hoffen, dass die bösen Jungs nicht.

    Dieser hat einige gute Effekte. Zuerst die schlechte Jungs können nicht nur machen Sie eine Liste der erwarteten Passwörter wie "Password1", hash in einer rainbow-Tabelle, und gehen Sie durch Ihre Passwort-Datei nach übereinstimmungen zu suchen. Wenn Sie haben eine gute zwei-byte-salt, Sie haben zu generieren 65.536 Werte für jede erwartete Passwort, und das macht die rainbow-table-viel weniger praktisch. Zweitens, wenn Sie können, halten Sie das Salz von den bösen Jungs, die schauen auf Ihre Passwort-Datei, die Sie gemacht haben es viel schwerer zu berechnen mögliche Werte. Dritten, Sie haben es unmöglich gemacht, für die bösen Jungs, um zu bestimmen, ob eine bestimmte person verwendet das gleiche Passwort auf verschiedenen Websites.

    Um dies zu tun, erzeugen Sie einen zufälligen salt. Diese generieren sollte jede Zahl im gewünschten Bereich mit gleichmäßiger Wahrscheinlichkeit. Dies ist nicht schwierig; eine einfache lineare congruential random number generator wird gut tun.

    Wenn Sie haben komplizierte Berechnungen zu machen, das Salz, du machst es falsch. Wenn Sie berechnen, basierend auf dem Passwort, dann machst du es so falsch. In diesem Fall, was Sie tun, ist kompliziert der Raute und funktional nicht jede Zugabe von Salz.

    Niemand gut auf die Sicherheit sich darauf verlassen, dass das verschweigen eines Algorithmus. Moderne Kryptographie wird auf algorithmen basiert, wurde ausführlich getestet, und damit ausgiebig getestet werden Sie müssen gut bekannt sein. In der Regel, es ist gefunden worden, um sicherer zu sein, verwenden Sie standard-algorithmen eher als rollende eigenen und der Hoffnung, es ist gut. Es spielt keine Rolle, wenn der code open source oder nicht, es ist oft noch möglich, die bösen Jungs zu analysieren, was ein Programm tut.

    InformationsquelleAutor der Antwort David Thornley

  4. 1

    Können Sie nur generieren einen zufälligen salt für jeden Datensatz zur Laufzeit. Zum Beispiel, sagen, du bist die Speicherung von Hash-Kennwörter in einer Datenbank. Sie können generieren eine 8-stellige zufällige Zeichenfolge, die der unteren und Großbuchstaben alphanumerische Zeichen zur Laufzeit voranstellen, dass an der Passwort-hash dass string und speichert ihn in der Datenbank. Da gibt es 628 möglich, Salze, generieren der rainbow-Tabellen (für jedes mögliche Salz -) teuer; und da Sie mit einem einzigartigen salt für jedes Passwort-Datensatz, selbst wenn es einem Angreifer generiert hat ein paar passende rainbow-Tabellen, die er noch nicht in der Lage zu knacken jeder Passwort.

    Ändern Sie können die Parameter Ihrer Salz-generation basiert auf dem security-Anforderungen; zum Beispiel, können Sie mehr Salz, oder Sie können eine zufällige Zeichenfolge generiert, die enthält auch Satzzeichen erhöhen die Anzahl der möglichen Salze.

    InformationsquelleAutor der Antwort mipadi

  5. 0

    Verwenden Sie eine zufällige Funktion-generator zu erzeugen, das Salz, und speichern es in die Datenbank, machen Salz einen pro Zeile, und speichern es in die Datenbank.

    Ich mag, wie Salz erzeugt wird, die in django-registration. Referenz: http://bitbucket.org/ubernostrum/django-registration/src/tip/registration/models.py#cl-85

    salt = sha_constructor(str(random.random())).hexdigest()[:5]
activation_key = sha_constructor(salt+user.username).hexdigest()
return self.create(user=user,
           activation_key=activation_key)

    Er verwendet eine Kombination der sha erzeugt von einer random-Nummer und den Benutzernamen zu generieren einen hash.

    Sha selbst ist bekannt für sein stark und unzerbrechlich. Fügen Sie mehrere Dimensionen zu generieren, die den salt selbst, mit zufälligen Zahl, sha und der Benutzer bestimmte Komponente, Sie unzerbrechlich Sicherheit!

    InformationsquelleAutor der Antwort Lakshman Prasad

  6. 0

    Im Fall einer desktop-Anwendung, die verschlüsselt die Daten und sendet diese an einen remote-server, wie sehen Sie mit einem anderen Salz jedes mal?

    Verwendung von PKCS#5 mit dem Passwort des Benutzers, er braucht Salz, um einen Verschlüsselungsschlüssel generieren, um die Daten zu verschlüsseln. Ich weiß, die halten das Salz hardcoded (obfuscated) in der desktop-Anwendung ist keine gute Idee.

    Wenn der remote-server müssen NIE das Kennwort des Benutzers kennen, ist es möglich, Benutzer verschiedene Salz-jedes mal? Wenn der Benutzer mithilfe der desktop-Anwendung auf einem anderen computer, wie wird es in der Lage sein, die Daten zu entschlüsseln, die auf dem remote-server, wenn er nicht über den Schlüssel (es ist nicht hardcoded in der software) ?

    InformationsquelleAutor der Antwort Normand Bedard

Schreibe einen Kommentar