Wie implementiere ich Salz in meinem login-Passwörter?

Ich umsetzen will, ein Salz in meinem login-system, bin aber ein bisschen verwirrt, wie das funktionieren soll. Ich verstehe nicht die Logik dahinter. Ich verstehe md5 ist ein Einweg-Algorithmus und alle Funktionen, die ich begegnet bin, scheinen hash-alles zusammen. Wenn dies der Fall ist, wie bekommt man das Passwort wieder aus zum Vergleich? Meine größte Frage ist, wie ist das Salzen eine Benutzer-Passwort sicherer als nur das Hashen des Passworts? Wenn eine Datenbank wurde jemals kompromittiert werden, wird der hash zusammen mit dem salt in der Datenbank. Ist das alles nicht, dass ein hacker brauchen würde?

Ich fand auch einen anderen post hier auf, DAMIT, wo ein anderer Entwickler sagte :

"Sicherzustellen, dass Ihre Salz-und-Algorithmus sind
gespeichert getrennt von der Datenbank"

Möchte ich speichern das Salz in der Datenbank. Ist das wirklich ein problem, wenn ich tun?

Ich bin auf der Suche nach etwas Hilfe, auf Verständnis, wie dies funktioniert und auch, was die beste Vorgehensweise sein könnte. Jede Hilfe wird sehr geschätzt.

BEARBEITEN:
Ich danke allen für Ihre Antworten und Ideen. Auch wenn ich möglicherweise mehr verwirrt nun, es ist sicherlich eine Erfahrung für mich. Nochmals vielen Dank Jungs.

Willkommen ALSO. Große erste Frage.
stackoverflow.com/questions/873403/net-impl-of-bcrypt
Verwandte Lesen: Die Rainbow-Table Ist Tot

InformationsquelleAutor Timmay | 2010-02-02

18

Einer hash-Funktion immer wieder den gleichen Wert für den gleichen Eingabe-string. Lassen Sie uns sagen, meine Benutzer (Alice) hat das Passwort secret. Hashing secret mit md5() führt zu der folgenden hash -
```
5ebe2294ecd0e0f08eab7690d2a6ee69
```
Mithilfe eines Wörterbuchs (eine Liste der häufigsten Wörter und Passwort) oder in einem der verschiedenen Websites, die Ihnen diesen Dienst, der Angreifer (Mallory) leicht finden können, das Passwort ist geheim, wenn er sieht, in seinem Wörterbuch, dass 5ebe2294ecd0e0f08eab7690d2a6ee69 = secret.

Den Prozess der Salzen vor Vermischung macht es schwieriger, verwenden Sie ein Wörterbuch-Angriff, ohne zu wissen, Ihr Salz. Betrachten Sie das folgende:
```
<?php
$salt = '@!#%$@#$@SADLkwod,sdaDwqksjaoidjwq@#@!';
$hash = md5($salt . 'secret');
```
Der resultierende hash wird nun b58ad809eece17322de5024d79299f8a aber Alice das Passwort ist immer noch secret. Wenn nun Mallory bekommt Ihr die Hände auf die gesalzenen hash, die Chancen sind Sie nicht finden die Antwort in Ihrem Wörterbuch. Wenn Sie nicht, das Wörterbuch werde Sie geben die falsche Antwort.

Speichern Sie niemals ein statischer salt in der Datenbank. Vorzugsweise speichern Sie es mit Ihrer Anwendung Konfiguration (was übrigens nicht verfügbar sein sollten aus dem Internet).

Wenn Sie gehen, um eine dynamische Salz, sind Sie gehen zu müssen, um die Datenbank verwenden. Verwenden Sie einen nicht-null-Spalte des vorhandenen gültigen Daten, bauen Sie Ihre Salz auf (blowfish-verschlüsselte string der Benutzername basiert auf einer geheimen Verschlüsselungs-Schlüssel wird in der Regel kryptografisch sicheren). Tun nicht verwenden Sie eine separate Spalte für den salt. Wenn Sie nicht verwenden Sie eine vorhandene Spalte, integrieren Sie Ihr Salz-in der gleichen Spalte, als Ihr hash. Verwenden Sie beispielsweise die ersten 32 Zeichen 128-bit Salz und dann die letzten 40, die für Ihre 160-bit-hash. Die folgende Funktion erzeugt eine solche hash:
```
function seeded_sha1($string, $seed_bits) {
    if(($seed_bits % 8) != 0) {
        throw new Exception('bits must be divisible by 8');
    }

    $salt = '';
    for($i = 0; $i < $seed_bits; $i+=8) {
        $salt .= pack('c', mt_rand());
    }

    $hexsalt = unpack('h*hex', $salt);

    return $hexsalt['hex'] . sha1($salt . $string);
}

function compare_seeded_sha1($plain, $hash) {
    $sha1 = substr($hash, -40);
    $salt = pack('h*', substr($hash, 0, -40));

    $plain_hash = sha1($salt . $plain);
    return ($plain_hash == $sha1);
}
```
Wenn ein Angreifer bekommt in Ihrer Datenbank mit Hilfe von SQL-injection, zumindest die hashes er/Sie ruft nicht hilfreich, da er/Sie nicht haben Zugriff auf Ihre Anwendung-Konfiguration. Wenn Ihr server bekommt verwurzelt, es ist ziemlich viel Spiel over, egal was Sie tun.

Hinweis: Es gibt andere Arten von Angriff möglich auf md5(), das ist, warum Sie die Verwendung sicherer Hash-Algorithmus, sha1() zum Beispiel. Oder, noch besser, verwenden Sie die Portable PHP password hashing framework, die wurde entworfen mit Sicherheit im Verstand und ist rückwärts kompatibel mit so ziemlich jeder PHP-version.
```
require('PasswordHash.php');

$pwdHasher = new PasswordHash(8, FALSE);

//$hash is what you would store in your database
$hash = $pwdHasher->HashPassword( $password );

//$hash would be the $hashed stored in your database for this user
$checked = $pwdHasher->CheckPassword($password, $hash);
if ($checked) {
    echo 'password correct';
} else {
    echo 'wrong credentials';
}
```
- Fantastisch, Erklärung Andrew. Danke. Gehen Sie nicht überall. Ich möchte Sie bitten, ein paar Fragen, nachdem ich zu Ende gelesen, den rest Ihrer post.
- Siehe chargen.matasano.com/chargen/2007/9/7/..., warum SHA-1 (oder SHA-2, oder von etwas anderem) ist nicht ein "sicherer Hash-Algorithmus", für das Passwort-hashing.
- Ok, sehen Sie, hier ist, was ist die Verschraubung mich... Jeder sagt zu generieren, die eine zufällige salt und in der Datenbank gespeichert. Scheint fair zu mir. Aber, was ich verstehe von deinem post ist, dass ich nicht speichern Sie den Hashwert in der Datenbank sondern in der Anwendung. Wenn ich speichern das Salz in der Anwendung, es nicht zu dynamisch sein an diesem Punkt. Können Sie sehen meine Verwirrung?
- Der gleiche Ansatz könnte auch genommen werden, mit bcrypt. Wörterbücher existieren für Sie als gut. Sie sind nur weniger verfügbar. Tut mir Leid zu sagen, Wörterbücher ist eine Schwäche, dass keine Hash-Algorithmus lösen kann. Wenn ich das nicht knacken Ihre bcrypt hash-genug Zeit, um mit einer Maschine, ich werde ein cluster. Wenn es immer noch nicht schnell genug, ich werde mieten Sie ein bot-Netz. Und Sie wissen nicht, wie schnell wir in der Lage sein, um hash ein bcrypt hash in einem Jahr. Seine vermeintliche Sicherheit durch Langsamkeit ist bereits gebrochen, fürchte ich.
- Nein, Sicherheit durch Langsamkeit ist die beste Verteidigung, die Sie haben, haben Sie zu verlangsamen, die brute-force-cracking, so viel wie Sie können. Wenn Sie sagen, es ist keine Verteidigung, dann ist das äquivalent zu sagen, dass jede Verschlüsselung ist nutzlos, weil die Menschen können brute-force-it. 😛
- das dynamische Salz wird nur verlangsamen Ihren Angreifer. Wenn Sie immer noch wollen, um eine dynamische Salz, machen Sie es nicht offensichtlich zu Ihrem Angreifer, und verwenden Sie ein Feld in der Zeile, die NICHT NULL ist, zu bauen, Ihr Salz auf. Das Schlimmste, was Sie tun können, ist ein Feld mit scheinbar zufällig, dass Sie oder schlimmsten, ein Feld namens salt.
- Der Tag einer Hash-Funktion ein, dauert mehr als 2 Sekunden, um zu berechnen, ich werde es prüfen sicher auf das Konto. Bis dann, ich kann einfach parallelisieren my brute-forcen so viel wie ich will um die Antwort zu bekommen ich möchte Sie schnell.
- Ich arbeitete für den Staat einen Antrag und hatte zu verwenden, Ihre Computer und das Netzwerk. Sie hatte ein extrem Sicheres Passwort-Algorithmus zum sperren von Passwörtern. Keine Wörter aus dem Lexikon, 2 groß-Buchstaben 3 zahlen, 16 Zeichen, die verändert werden musste, alle 20 Tage. Ich war laufen rund um das Büro suchen, für die Seriennummern aus der HP-Drucker zu verwenden.
- Sie offensichtlich nicht gelesen haben, auf bcrypt, dann. bcrypt Sieg ist, dass es tunable. In dem moment, wenn Sie, sagen wir, 12-log-Runden, später können Sie es bis zu, sagen wir, 15-log-Runden. Jedes zusätzliche Protokoll-Runde verdoppelt sich die Anzahl der Runden verwendet, um zu berechnen, eine Passwort-Prüfung. Und ich kann Wetten, dass Sie, dass jetzt ein 15-log-Runde Salz nehmen weit mehr als 2 Sekunden, um zu versuchen.
- Was ist sicherer? Eine zufällige Salz oder ein statischer salt? Wenn Sie sagen, static, dann ist das der Weg, den ich gehen werde. Würden Sie empfehlen, bcrypt?
- -1: Schlechte Antwort. Der richtige Weg, um ein Salz zu erzeugen, einen zufälligen salt für jeden Benutzer und in der Datenbank gespeichert. Versuchen, Sie zu halten getrennt oder verdecken der name des Feldes ist naiver Unsinn. Und mit einer künstlich langsame hash-Funktion ist sehr viel einer anerkannten guten Praxis.
- Verwenden Sie einen zufälligen salt. Sie wird (geringfügig) erhöhen Sie die Sicherheit, dass die Art und Weise, für die meisten algorithmen. In dem speziellen Fall, bcrypt, die Anzahl der log-Runden verwendet wird, ist codiert in das Salz, so mit einen anderen salt für jedes Passwort, können Sie inkrementell aktualisieren, um stärker und stärker hashing.
- Bearbeitet meine Antwort auf das, was ich meinte ursprünglich. Für dynamische Salze, die Sie brauchen, um es zu speichern in die Datenbank, aber nicht fügen Sie ein Feld für Sie. Verwenden Sie einen vorhandenen Bereich von gültigen Daten und die Verschlüsselung basiert auf einer statischen privaten geheimen Schlüssel. Das ergibt eine kryptografisch sichere hash.
- Ich behaupte nicht, ein Experte zu sein, und das ist der Grund, warum ich hier bin, aber es scheint mir, dass, wenn ich hatte ein statischer Schlüssel (salt) und ich war die EINZIGE person die Kontrolle über das Salz, dann ein hacker nicht in der Lage wäre zu knacken der hashes. Ich meine, es scheint logisch, für mich jedenfalls. Könnten Sie bitte erklären, wie die Speicherung eines zufälligen salt ist sicherer als ein statischer salt?
- Wenn der salt bekannt wird, es ist einfach zu neu erstellen ein Wörterbuch, da es nur einen zu bauen. Das dynamische Salz macht es schwieriger, wie Sie brauchen, um zu bauen X-Wörterbücher, eine für jede Zeile.
- Die Gefahr ist, dass Sie Ihren Angreifer kann Zugriff auf alle Ihre Website-code als auch als alle die Tabellen in der Datenbank. Wenn Sie an Sicherheit denken, von einem "worst-case-Szenario" point of view, dann hast du alles abgedeckt (so gut wie möglich jedenfalls).
- Was meinst du mit speichern, die dynamischen salt-in "ein vorhandenes Feld gültige Daten"? Sollte ich speichern das Salz in mit sagen, die E-Mail-Adresse oder Benutzername? Auch... Sie reden jetzt über die Verwendung einer statischen privaten Schlüssel. Gibt es ein code-snippet, das ich mir ansehen kann, so dass ich vielleicht verstehen kann, dieses ein bisschen mehr sein? Zugegeben, ich bin mehr verloren, als ich kam in hier. 🙂
- Wenn Sie bcrypt, das Salz gespeichert wird, mit dem Hash-Passwort. Die Bibliothek kümmert sich um alles für Sie automatisch.
- Jester-Jungen, die Sie nicht verwenden zufällige Salz, yould wie Sie überprüfen können Benutzer-Passwort, falls Sie es nicht haben letztes zufällig generierten salt?
- Nein, Sie kann aber, sagen Sie, eine verschlüsselte version des E-Mail-Adresse. So sind Sie mit vorhandenen Daten, aber es ist nicht offensichtlich, beim betrachten der Tabelle layout.
- Borgwardt die Sie nicht haben, um eine eindeutige Salze für jeden Benutzer, verwenden Sie einfach schon zugänglich Spalten als ich wies in meiner Antwort stackoverflow.com/questions/2188507/...
- Die random-salt gespeichert ist (im klaren) mit das gehashte Kennwort. Das Salz braucht es nicht wirklich geheim sein, wenn es einmalig per Passwort.
- Security by obscurity wird dir nicht helfen. Davon ausgehen, dass Ihre Angreifer können laden Sie eine vollständige Kopie Ihres Quellcodes dann entscheiden, ob mit "verschlüsselte E-Mail-Adresse" ist besser als nur das speichern einer zufälligen Salz in die klare mit Ihrem gehashte Kennwort.
- Wie ich bereits sagte, sobald Sie verwurzelt sind, es ist ziemlich viel Spiel over. Aber mit Zugriff auf den Quellcode, ich kann mir einen Haufen einfacher Weg, um Zugriff auf das Passwort, mit dem eine schnellere Rückkehr als die Verarbeitung von hashes. Wenn der hash nicht ersichtlich ist, in der Datenbank, so wird es viel schwieriger für einen Angreifer mit Zugriff auf die Datenbank nur.
- Aber warum verwenden Sie ein anderes Salz, falls Sie bereits persistent, nicht ändern der Spalten, die Sie verwenden können, wie ein Salz in Kombination mit einem statischen salt?
- Das macht durchaus Sinn, auch für mich.
- Es gibt Möglichkeiten zu erhalten, eine web-Anwendung Quellcode, die nicht die erste volle "game-over" root-Zugriff, oder sogar den Zugang zum ändern der Sprach-code (das wäre, wie du sagst, zugeben, viel einfacher Angriffe wie die Protokollierung alle Passwörter eingegeben werden).
- schaue auf meine Antwort auf eine Erklärung re "statischer Schlüssel". @juraj: eine generierte Salz hat den Vorteil, dass Sie sicherstellen können, seine Länge und Qualität mehr leicht - und es wird verhindert, dass dem Kunden erklären, dass es unmöglich ist die änderung einiger Felder, weil Ihre Sicherheits-Konzept hängt Sie fest.
- wenn Sie Zugriff auf source code (root oder einer anderen Art), ist es ziemlich totally Spiel über, aus dem Quellcode kann man studieren, alle Injektionen und Pannen können Sie ausführt, dass die DB bleibt ziemlich ungeschützt 🙂
- Falsch. Sichere software hängt nicht von der Geheimhaltung des Quellcodes für seine Sicherheit. Ihre Sicherheit kommt von gut-codiert in den ersten Platz. Sie wissen schon, die Leute können das reverse-Engineering alle Aspekte der closed-source-Produkten; wo glauben Sie, dass die Microsoft security advisories kommen? (Hinweis: IDA Pro.)
- reverse engineering-von einer einfachen Aufgabe wie Benutzer login/logout, die ausgeführt wird, auf der server-Seite ist ziemlich unmöglich (wie du gesagt hast, wenn gut programmiert).. hovewer getting user info, mit Hilfe von manipulierten Quellcode ist viel einfacher.. in der Summe, denke ich, dass dieser Kommentar-Abschnitte sind ziemlich lang und es fängt an umstritten sein:-D
- Ich kommentierte in Ihrem Beitrag unten, Fragen Sie für Ihre Meinung, wie Sie gehen könnte, über das sperren von Passwörtern, wenn es bis zu Ihnen. Ich möchte hier zu verlassen, mit etwas. 🙂
- -1 für "Nie speichern das Salz in Ihren Datenbanken." Es gibt keinen Grund, nicht zu speichern, die Salze in der Datenbank, allerdings sollten Sie für jeden Benutzer eindeutig oder es ist nutzlos. Und natürlich ist es kein problem mit der Verwendung einer einzigartigen Datenbank-Feld für die Salze, da die das Salz ist nicht als ein Geheimnis.
- Sie offensichtlich aufhören zu Lesen in der Mitte der post. Und während das Salz ist nicht als ein Geheimnis, wenn nur Ihre Datenbank kompromittiert ist, stützen Sie Ihre Salz auf ein vorhandenes Feld wird erheblich behindern die Fähigkeit von einem Angreifer in der Lage sein, um Zugang zu einem bestimmten Konto. Wenn das Salz ist klar, in der Datenbank und der Angreifer ist nur daran interessiert, in einem bestimmten Konto, ist es deutlich einfacher für ihn zu bauen, ein Wörterbuch, um zu versuchen und finden Sie das Passwort (wenn das Sprach-Passwort ist nicht sicher).
- "stützen Ihr Salz auf ein vorhandenes Feld wird erheblich behindern die Fähigkeit von einem Angreifer in der Lage sein, um Zugang zu einem bestimmten Konto" - nun, warum in der Welt würden Sie denken, dass? Ich hoffe, du bist nicht gehen zu behaupten, dass es "security by obscurity"? 🙂
- Nehmen wir an, der Angreifer hat nur Zugriff auf Ihre Datenbank. Wenn Sie als Basis für Ihr Salz auf einem blowfish-verschlüsselte version deiner E-Mail-Adresse (zum Beispiel), die Angreifer so absolut keine Möglichkeit, herauszufinden, das Salz und nicht bauen kann, ein Wörterbuch für ein bestimmtes Konto. Er muss nicht Ihre Schlüssel, und er hat nicht einmal die Verschlüsselungs-Methode verwendet. Einfach über ein Feld, wie es ist, nicht einen beliebigen Wert haben, da seine "security-by-obscurity", aber die Anwendung einer operation (wie z.B. Verschlüsselung) nicht verhindern, dass ein Angreifer nur Zugriff auf die DB zu tun, nichts mit den hashes.
- Chris Jester-Young ist richtig an jeder Stelle so weit.
- Erstaunliche Diskussion, und sehr zu informieren. Vielen Dank an alle. Und es sollte SO ein Abzeichen dafür, dass die erste Frage Rakete so weit. 🙂
- Das ist neben dem Punkt. Leute, reverse-engineer, weil Sie haben Zugang zu den binaries. Wenn Sie nicht über einen Internetzugang verfügen, um weder die Quelle noch die Binärdateien, Sie werden mir Zustimmen, dass das reverse-engineering wird viel schwieriger (nicht unmöglich, schwieriger).
- -1 für "ein nicht-null-Spalte des vorhandenen gültigen Daten, bauen Sie Ihre Salz". Dies würde die Band es, das verschlüsselte Passwort zu einigen anderen Daten, das ist schlecht. Verwenden Sie einen sicheren Zufallszahlengenerator, der zum generieren der salt für jedes Passwort. Oder verwenden Sie eine Bibliothek, die nicht salting und hashing für Sie und speichern Sie alle Ihre Daten, einschließlich Salz als das gehashte Kennwort.
- Im letzten code-Beispiel kopiert von: stackoverflow.com/questions/1581610/...
- Im letzten code-Beispiel kopiert aus dem PHP-Passwort-Hashing-Dokumentation. Bitte Holen Sie Ihre Referenzen gerade.
- Moore: dann bitte den link der URL mit diesem code-Beispiel und ich stehe korrigiert. (Google kann es nicht finden und ich deutlich erinnere mich an genau diesem Beispiel.)
- Sehen test.php aus dem 0,1 Verteilung der phppass.
- Moore: Alle Versionen von test.php sind hier: cvsweb.openwall.com/cgi/cvsweb.cgi/projects/phpass Der code-block ist nicht drin. Also ich stehe zu meiner ursprünglichen Forderung.
InformationsquelleAutor
31

Dem Punkt ein Salz ist zu verhindern, dass Angreifer aus der Amortisation der Kosten für brute-force-Angriffe auf Websites (oder noch besser, wenn mit einem anderen Salz für jeden Nutzer: alle Nutzer einer site) durch vorausberechnete Regenbogen-Tabellen.

Mit einfachem hashing, kann ein Angreifer berechnen Sie eine solche Tabelle einmal (ein sehr langer, kostspieliger Vorgang) und dann verwenden Sie es, um schnell zu finden Passwörter für jede Website. Wenn eine Website verwendet eine Feste Salz -, muss der Angreifer berechnen Sie eine neue Tabelle, die speziell für diese Website. Wenn eine Website verwendet ein anderes Salz für jeden Benutzer kann der Angreifer Hör auf mit rainbow-Tabellen - er haben werde, um brute-force jedes einzelne Kennwort separat.

Speicherung der Salze getrennt ist nicht notwendig, diesen Vorteil zu erlangen. In der Theorie wäre es sogar sicherer, da es würde neutralisieren die Schwäche Wörterbuch oder kurze Passwörter. In der Praxis ist es nicht Wert die Mühe mit denn am Ende des Tages, müssen Sie Zugriff auf die Salze irgendwo zu überprüfen Passwörter. Auch, versuchen, Sie zu trennen würde dazu führen, dass mehr komplexe Systeme - und je komplexer ein system ist, desto mehr Möglichkeiten für Sicherheitslücken es gibt.

Edit: Meine konkreten Empfehlungen:
- Generieren langen Pseudo-zufälligen salt für jeden user und speichern in die DB
- Verwenden Sie ein bcrypt-hash-basierte
- ideal, nicht es selbst implementieren, verwenden Sie eine vorhandenen Bibliothek statt
- Dank Mike. So, es ist wie 6 zu 1, ein halbes Dutzend zu dem anderen... Wenn es waren Sie, wie würden Sie dies tun? Was ist die beste Praxis in Ihrem eigenen Geist?
- Vielen Dank Michael. Ich bin sicher, dass Ihr wahrscheinlich müde von diesem thread jetzt aber hätten Sie etwas dagegen, die Beantwortung von ein paar Fragen? Ich bin derzeit auf 5.3 und Krypta ist Teil der Distribution. Wenn Sie sagen, verwenden Sie eine vorhandene lib, ist die Benutzung der PHP crypt Funktion ok oder nicht?
- +1 große abschließende Beratung. @Timmay Dies verdient die große grüne Häkchen 🙂
- Ist es OK, aber die phpass Bibliothek, die ich verlinkt wäre noch besser. Es wäre wahrscheinlich sparen Sie sich einige Arbeit und hat automatische fallbacks, die verwendet wird, wenn das system hat zu laufen, auf eine ältere PHP-version.
- Genau wie Michael Borgwardt gesagt und das darf nicht unterschätzt werden gesehen, die Ebene von Fehlinformationen in vielen Antworten. Michael ist vor Ort: "die Speicherung von Salzen getrennt ist nicht notwendig, diesen Vorteil zu erlangen". Der ganze Punkt von Salzen zu verhindern, dass rainbow-tables Angriff. Salz, auch in der klaren, und dieses dann perfekt dient diesem Zweck.
InformationsquelleAutor Michael Borgwardt
15

Vergessen über die Verwendung von Salzen (teilweise aus dem Grund, die Sie erwähnen), verwenden Sie bcrypt statt:

Für eine gute Erklärung finden Sie unter: http://codahale.com/how-to-safely-store-a-password/
- Und die große Sache über bcrypt? Es widerspricht dumme Behauptungen wie speichern das Salz getrennt von den hash.... 😛 (+1 für die Erwähnung bcrypt; ich 100% Zustimmen.)
- lol.. ich mag die Autorin Sinn für humor. Es ist ein großer Lesen. Danke. 🙂
- Gut, wenn bcrypt ist ein besserer Weg zu gehen, dann das ist, was ich verwenden würde.
- Ja, bcrypt ist der beste Weg zu gehen. Nicht mit MD5 oder SHA1; diese Art der Beratung wird überholt von mindestens 20 Jahren (so zu sagen). Siehe: chargen.matasano.com/chargen/2007/9/7/...
- bcrypt ist der beste Weg zu gehen, bis das Gegenteil bewiesen gebrochen. Alle hashing-Algorithmus, durch die pure definition eines hashing-Algorithmus, das bedeutet, man Eingabe = Ausgabe auf. Die Geschwindigkeit, gibt keine Sicherheit (wer weiß, welche Geschwindigkeiten wir in der Lage sein zu berechnen, die in einem Jahr). Und wenn ein computer ist nicht genug, um brute-force Ihre bcrypt hash, ich werde laufen meine software auf einem freaking botnet, das Ergebnis zu erhalten. Mein Punkt ist, dass bcrypt ist nicht sicherer als alle salt+hash um.
- Ok, also der PHP-crypt-Erweiterung verwenden können, Blowfish, aber Sie immer noch übergeben zu müssen, ein 16 char Salz - du bist wieder da wo du angefangen hast, nicht?
- Wenn es bedeutet, dass Ihre Angreifer zu beschäftigen 1000x mehr botnet-Knoten, das Kennwort zu knacken, das ist nur draufgelegt ziemlich viel. (Und das 1000x bezieht sich nur auf PHK-Algorithmus, der 1000-Iterationen-MD5; bcrypt ist sogar noch langsamer als das.)
- Von dem, was ich von schnell Lesen, der link war, der blowfish ist ultra langsam, so dass es härter und viel mehr Zugriff auf das Passwort.
- Ja, genau, und das ist, wo das gewinnen ist.
- Danke Chris. Ich bin alles über die Logik und macht etwas so langsam scheint das ticket. Muss ich irgendetwas installieren oder spezielle kompilieren Sie PHP verwenden bcrypt?
- Laut dem link, Reich gepostet, ist dies eine vernünftige Umsetzung von bcrypt in PHP (wenn unten 5.3.0): openwall.com/phpass (Sie sagen, dass 5.3.0+ bereits vordefiniert.)
- Ah, cool. Ich bin schon am 5.3 also ich denke, es ist schon dort. 🙂 Zumindest etwas ist Trinkgeld in meiner Gunst heute.
- -1 bcrypt ist ein großes Werkzeug für diesen job, aber Sie sollte noch Salze (für die bereits oben genannten Gründen von Andrew) - das Salz löst ein anderes problem als der hash. Der Autor dieses Artikels ist falsch.
- Wo ist NBcrypt?
- Sie sind völlig falsch! bcrypt hat die einzigartige pro-Kennwort Salz in die endgültige hash. Es kümmert sich um alles, so dass alles in Ordnung ist mit ihm.
InformationsquelleAutor Rich
7

Die anderen Antworten sind gut, so werde ich nur werfen Sie in eine kleine Stelle, die sonst niemand erwähnt hat. Sie don ' T wollen, verwenden Sie ebenfalls den gleichen salt für jedes Passwort, weil dann, wenn zwei Menschen das gleiche Kennwort haben, müssen Sie den gleichen hash. Das bereitstellen von Informationen, die ein Angreifer ausnutzen kann.

Können Sie den gleichen salt für alle Benutzer zusammen mit Juraj ist eine gute Idee, kombiniert das Kennwort mit anderen nicht-änderung der Datenbank-Felder (nur für einen Benutzer). Aber aufpassen, da diese Informationen bekommt gebunden an das Passwort. Wenn Sie hash des Benutzernamen + Passwort zusammen garantieren einen eindeutigen hash, Sie wäre nicht in der Lage, ändern Sie den Benutzernamen-ohne einen neuen Benutzer zu erstellen und Ihnen zu verlangen, sich ein neues Passwort setzen.

Als ein Beispiel für eine einzigartige Salz pro Benutzer und speichern Sie neben dem Passwort-hash, ich werde darauf hinweisen, /etc/shadow auf der typischen Linux-system.
```
root@linux:/root# cat /etc/shadow | grep root
root:$1$oL5TTZxL$RhfGUZSbFwQN6jnX5D.Ck/:12139:0:99999:7:::
```
Hier, die oL5TTZxL ist das Salz und RhfGUZSbFwQN6jnX5D.Ck/ ist der hash. Die nur-text-Kennwort ist root in diesem Fall, und der hash-Algorithmus, der mein system verwendet wird, ist der MD5-basierten BSD-Passwort-Algorithmus. (neuere Systeme, als meine bessere hash-algorithmen)
- Indiv, danke.., die durchaus Sinn machen. So dass ich wirklich brauchen, um darüber nachzudenken, was ich will-hash. Was ist hashing der Benutzer das Passwort zusammen mit einem statischen Schlüssel, die nur ich wissen? Ein Schlüssel, der sich in meine Anwendung ein?
- Ein statischer Schlüssel würde eine zusätzliche Ebene der Verschleierung, aber es ist angemessen, bei der Auswertung Sicherheit davon ausgehen, dass ein Angreifer hat alle wissen über Ihr system, einschließlich source-code. In diesem Fall wird dieser statische Schlüssel ist nur eine statische Salz, und die nicht wesentlich erhöhen die Sicherheit Ihres Systems.
- Und ich denke, es sollte darauf hingewiesen werden, dass die Linux security track record könnte als ganz gut und Sie sind offensichtlich zu speichern das Salz in der klaren in der 'DB'. Der ganze Punkt von Salz zu verhindern, dass rainbow-tables Angriff. Hinweis: brute-force-Attacken. Mit ein Salz in der klar ist nicht ein Problem überhaupt, da es voll erfüllt seinen Zweck: Sieg über rainbow-tables Angriff. Speichern Salz in der klar ist, ist nicht nur gemein, aber normal: es ist nicht Ihre Sicherheit mehr anfällig für eine brute-force-Angriff. Zu sagen, dass das Salz sollte nicht gespeichert werden, in der klar ist albern.
InformationsquelleAutor indiv
5

Bekommen Sie nicht, das Kennwort für den Vergleich. Sie verschlüsseln Sie das Kennwort, wenn Sie versuchen, einen login und vergleichen der gespeicherte Wert mit den neu verschlüsselten Wert.
- Ja, weil das hashing eines Wertes wird zu der gleichen hash-jedes mal, wenn Sie vergleichen Sie einfach die beiden hashes.
- Ok, soviel bekomme ich. Ich Tat dies vor, aber jetzt, ich möchten, verwenden Sie ein Salz, das verstehe ich nicht. Ich denke, was ich habe eine harte Zeit zu verstehen ist, wie das Salzen ein Passwort ist sicherer als nicht Salzen. Das Salz wird in der Datenbank zusammen mit dem hash. Wenn ein hacker hatte die Datenbank, wie ist das sicherer?
- Ein besserer Ansatz könnte sein, zu hemmen Wörterbuch-Attacken zusammen. Sie können eine maximale login-Versuch zählen, oder erhöhen Sie die Zeit zwischen den login-versuchen (z.B. durch eine Potenz von n) durch die Umsetzung einer Verzögerung. Dies macht es sehr schwierig, zu versuchen, mehr als ein paar Passwörter in einer angemessenen Höhe der Zeit.
- Wenn du redest, maximale login-versuche, die Sie suchen an der falschen threat model. Die Recht bedrohlich Modell ist, dass ein cracker hat gerade heruntergeladen haben, Ihre ganze Benutzer - /Passwort-Tabelle, und will zu knacken, so viele Passwörter wie Sie können.
- alle vorbeugenden Ansatz in isolation ist im wesentlichen nutzlos. Ich war nicht darauf hindeutet, es als eine alles umfassende Narr Beweis-Ansatz.
- Vielleicht. Aber all dieses Gerede über den maximalen versuche ist völlig orthogonal, um den Zweck der mit gesalzenen Passwort-hashing (was die OP ' s Frage); die erste richtet sich an online password guessing attacks, wobei letzteres zielt auf offline-cracking-Angriffe.
InformationsquelleAutor brian
2

Als Sie erwähnt, hashing algorithmen funktionieren nur in einer Richtung (oder nur wenn Sie stark genug sind :-D)

Deiner Frage, Salzen würde ich empfehlen, ein Kennwort hash mit einem statischen salt-string und einige dynamische Daten aus der Datenbank, die sollte nicht ändern nachdem Sie einmal erstellt

Dies ist eine sehr sichere Art der Speicherung von Passwörter, selbst wenn die Datenbank kompromittiert wird, die Hacker/Cracker immer noch brauchen, um Ihre statische string-hash und müssen erraten, wie Sie angewandt allen Salzen..

Zum Beispiel lassen Sie uns sagen, Sie haben eine users Tabelle mit diesen Spalten:
```
id
username
password
created_at
```
Spalten id und created_at nach einmal gefüllt, sollten niemals geändert werden..

so, wenn Sie sind hashing-Benutzers Kennwort, das Sie tun können, so einfach wie:
```
<?php
    $staticSalt = '!241@kadl;ap][';
    $userPass = 'my new pass';
    //assuming $user variable is already populated with DB data
    //we will generate new hash from columns and static salt:
    $genPass = sha1($user['id'] . $userPass . $user['created_at'] . $staticSalt);
?>
```
Ich hoffe, das hilft 🙂 cheers

InformationsquelleAutor Juraj Blahunka
2

Hashing der Passwörter gemeint ist, um diese Passwörter geheim von Ihrem eigenen administrator(en).

1) Halten Sie Passwörter im Klartext in Ihrer Datenbank wäre in Ordnung, außer Ihre Passwörter können vom administrator verwendet, um den Zugang zu einem anderen system.

2) können Sie eine einzige Globale Salz, die in Kombination mit den Passwörtern (durch voranstellen oder XORing) und dann das hashing für die Speicherung in der Datenbank. Das ist aber anfällig für einen administrator UND eine rainbow-table ausgelegt, dass ein Salz.

3) Sie können einen separaten Salz für jeden Benutzer: Die Datenbank wird zum speichern des salt und der hash-abgeleitet von dem Kennwort/salt-Kombination. Dies verhindert eine rainbow-table-Angriff, aber brute-force-Angriffe sind weiterhin möglich.

4) Schließlich können Sie Ihre hash-Funktion einen geheimen durch die Verwendung eines Geschwindigkeits-beschränkten hardware-hashing-Lösung.

Das ist so gut wie Sie tun können. Weil der menschlichen Natur, die Passwörter haben eine begrenzte Domäne und sind anfällig für brute-force-Angriffe. Wir versuchen zu verhindern, dass Administratoren immer ein halten Sie Benutzer-Passwörter, und dann verwenden Sie Sie auch auf anderen Systemen, die Sie keinen Zugriff haben sollten.

Einige andere Notizen:

a) können Sie bcrypt auf die Kennwort-Salz-Kombination zu verlangsamen die Angreifer brute-force-Angriff. Da wir aber davon aus, Administratoren, Sie können geduldig sein.

b) Halten Sie das Salz getrennt von den Kennwort-hash ist keine wirksame Verteidigung, die wir sind, vorausgesetzt, Administratoren, nachdem alle.

c) Verwendung vorhandener Daten als Salz ist ein wenig besser, aber ich bezweifle, dass vorhandene Daten, wie viel Entropie eine zufällige Salz hat.
- Dank Kyle.. ich bin immer noch hier, versucht, herauszufinden, wie zu verwenden bcrypt. Haben Sie benutzt, bevor es als Bestandteil der PHP-Distribution?
- Der "administrator" könnte auch jemand sein, der gefunden hat, eine SQL-Injektion Loch in Ihrer Seite und hat Sie weggeworfen aus Ihrem DB-schema und den Inhalt der user-Tabelle.
- Guter Punkt, über den Administratoren. Ich bin stolz zu sagen, dass selbst ich, als designer der unser Kennwort-system konnte nicht herausfinden des Passworts eines jeden Benutzers, ohne einen brute-force-Angriff. Wenn ich es nicht tun kann, wie jemand mit weniger wissen über das system gehen?
InformationsquelleAutor Kyle Lahnakoski
1

Salzen Sie das Kennwort eines Benutzers ist möglicherweise sicherer als hashing nur das Passwort, denn es kann zum Schutz gegen precomputation Angriffe.

Zum Beispiel, wenn ein hacker bekommt Zugriff auf Ihre Datenbank und die Passwörter sind nicht gesalzen, dann kann er schauen, bis die hashes in seiner Datenbank mit hashes (siehe http://en.wikipedia.org/wiki/Rainbow_table), um die ursprünglichen Passwörter.

InformationsquelleAutor Sam Hartsfield

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.