verschlüsselung - Sichere Hash und Salz für PHP Passwörter




php verschlüsselung sha256 (10)

Es wird derzeit gesagt, dass MD5 teilweise unsicher ist. Wenn ich das in Betracht ziehe, würde ich gerne wissen, welcher Mechanismus für den Passwortschutz verwendet werden soll.

Diese Frage, ist "doppelte Hashing" ein Passwort weniger sicher als nur einmal Hashing? schlägt vor, dass Hashing mehrere Male eine gute Idee sein kann, während Wie Sie den Passwortschutz für einzelne Dateien implementieren? schlägt vor, Salz zu verwenden.

Ich benutze PHP. Ich möchte ein sicheres und schnelles Passwort-Verschlüsselungssystem. Ein Passwort millionenfach zu hacken ist zwar sicherer, aber auch langsamer. Wie erreiche ich ein gutes Gleichgewicht zwischen Geschwindigkeit und Sicherheit? Außerdem würde ich bevorzugen, dass das Ergebnis eine konstante Anzahl von Zeichen hat.

  1. Der Hashing-Mechanismus muss in PHP verfügbar sein
  2. Es muss sicher sein
  3. Es kann Salz verwenden (in diesem Fall sind alle Salze gleich gut? Gibt es eine Möglichkeit, gute Salze zu erzeugen?)

Sollte ich zwei Felder in der Datenbank speichern (eines mit MD5 und eines mit SHA)? Wäre es sicherer oder unersättlicher?

Falls ich nicht klar genug war, möchte ich wissen, welche Hashfunktion (en) zu verwenden sind und wie man ein gutes Salz auswählt, um einen sicheren und schnellen Passwortschutzmechanismus zu erhalten.

Verwandte Fragen, die meine Frage nicht ganz abdecken:

Was ist der Unterschied zwischen SHA und MD5 in PHP?
Einfache Passwortverschlüsselung
Sichere Methoden zum Speichern von Schlüsseln, Passwörter für asp.net
Wie würden Sie in Tomcat 5.5 gesalzene Passwörter implementieren?

https://code.i-harness.com


HAFTUNGSAUSSCHLUSS : Diese Antwort wurde 2008 geschrieben.

Seitdem hat PHP uns php.net/manual/en/function.password-hash.php und password_verify und seit ihrer Einführung sind sie die empfohlene Hashing- und Prüfmethode für Passwörter.

Die Theorie der Antwort ist jedoch immer noch eine gute Lektüre.

TL; DR

Don'ts

  • Beschränken Sie nicht, welche Zeichen Benutzer für Kennwörter eingeben können. Nur Idioten machen das.
  • Beschränken Sie nicht die Länge eines Passwortes. Wenn Ihre Benutzer einen Satz mit supercalifragilisticexpialidocious darin wollen, verhindern Sie nicht, dass sie ihn benutzen.
  • Speichern Sie niemals das Passwort Ihres Benutzers im Klartext.
  • Senden Sie niemals ein Passwort an Ihren Benutzer, es sei denn, Sie haben eines verloren, und Sie haben ein temporäres gesendet.
  • Passwörter niemals auf irgendeine Weise auf.
  • SHA1 niemals Passwörter mit SHA1 oder MD5 oder sogar SHA256! Moderne Cracker können 60 bzw. 180 Milliarden Hashes / Sekunde überschreiten.
  • Mischen Sie nicht bcrypt und mit der rohen Ausgabe von hash () , verwenden Sie entweder Hex-Ausgabe oder base64_encode es. (Dies gilt für alle Eingaben, die möglicherweise einen Rogue \0 , der die Sicherheit ernsthaft schwächen kann.)

DOS

  • Verwenden Sie scrypt, wenn Sie können; bcrypt wenn du nicht kannst.
  • Verwenden Sie PBKDF2, wenn Sie weder bcrypt noch scrypt mit SHA2-Hashes verwenden können.
  • Setzen Sie alle Passwörter zurück, wenn die Datenbank kompromittiert ist.
  • Implementieren Sie eine angemessene Mindestlänge von 8-10 Zeichen plus mindestens 1 Großbuchstaben, 1 Kleinbuchstaben, eine Zahl und ein Symbol. Dies verbessert die Entropie des Passworts und macht es dadurch schwieriger zu knacken. (Siehe Abschnitt "Was macht ein gutes Passwort?" Für einige Diskussionen.)

Warum Hash-Passwörter sowieso?

Das Ziel hinter Hash-Passwörtern ist einfach: Verhindern bösartigen Zugriffs auf Benutzerkonten durch Kompromittierung der Datenbank. Das Ziel von Password Hashing ist also, einen Hacker oder Cracker davon abzuhalten, zu viel Zeit oder Geld zu investieren, um die Klartextpasswörter zu berechnen. Und Zeit / Kosten sind die beste Abschreckung in Ihrem Arsenal.

Ein weiterer Grund, warum Sie einen guten, robusten Hash für ein Benutzerkonto wünschen, ist, dass Sie genug Zeit haben, um alle Kennwörter im System zu ändern. Wenn Ihre Datenbank kompromittiert ist, benötigen Sie genügend Zeit, um das System zumindest zu sperren, wenn Sie nicht jedes Passwort in der Datenbank ändern.

Jeremiah Grossman, CTO von Whitehat Security, erklärte in seinem Blog nach einer kürzlich erfolgten Wiederherstellung des Passworts, bei der sein Passwortschutz brachial war:

Interessanterweise habe ich, als ich diesen Albtraum erlebte, gelernt, dass ich nichts über Passwort-Cracking, Speicher und Komplexität wusste. Ich habe erkannt, warum die Speicherung von Passwörtern wichtiger ist als die Komplexität von Passwörtern. Wenn Sie nicht wissen, wie Ihr Passwort gespeichert ist, können Sie sich nur auf Komplexität verlassen. Dies ist zwar für Kennwörter und Krypto-Profis allgemein bekannt, aber für den durchschnittlichen InfoSec- oder Web-Security-Experten bezweifle ich es sehr.

(Hervorhebung von mir.)

Was macht ein gutes Passwort überhaupt?

Entropy . (Nicht, dass ich Randalls Standpunkt voll und ganz unterschreibe.)

Kurz gesagt, Entropie ist, wie viel Variation innerhalb des Passworts ist. Wenn ein Passwort nur aus kleinen Buchstaben besteht, sind das nur 26 Zeichen. Das ist nicht viel Variation. Alphanumerische Passwörter sind besser, mit 36 ​​Zeichen. Aber Groß- und Kleinschreibung mit Symbolen ist etwa 96 Zeichen lang. Das ist viel besser als nur Buchstaben. Ein Problem besteht darin, dass wir Muster einfügen, um unsere Passwörter unvergesslich zu machen - was die Entropie reduziert. Hoppla!

Die Passwort-Entropie wird leicht approximated . Die Verwendung des vollen Bereichs von ASCII-Zeichen (etwa 96 typisierbare Zeichen) ergibt eine Entropie von 6,6 pro Zeichen, die für ein Passwort nach 8 Zeichen noch zu niedrig ist (52,679 Bit Entropie) für zukünftige Sicherheit. Aber die gute Nachricht ist: längere Passwörter und Passwörter mit Unicode-Zeichen erhöhen wirklich die Entropie eines Passworts und machen es schwieriger zu knacken.

Es gibt eine längere Diskussion der Passwort-Entropie auf der Crypto StackExchange- Website. Eine gute Google-Suche wird auch viele Ergebnisse ergeben.

In den Kommentaren sprach ich mit @popnoodles, die darauf hinwiesen, dass das Erzwingen einer Passwort-Policy der X-Länge mit X vielen Buchstaben, Zahlen, Symbolen usw. die Entropie tatsächlich reduzieren kann, indem das Passwortschema berechenbarer wird. Ich stimme zu. Randomess, so zufällig wie möglich, ist immer die sicherste, aber am wenigsten denkwürdige Lösung.

So weit ich sagen konnte, ist das Catch-22 das weltweit beste Passwort. Entweder es ist nicht einprägsam, zu vorhersehbar, zu kurz, zu viele Unicode-Zeichen (schwer auf einem Windows / Mobile-Gerät eingeben), zu lang, etc. Kein Passwort ist wirklich gut genug für unsere Zwecke, also müssen wir sie schützen, als ob sie waren in Fort Knox.

Best Practices

Bcrypt und scrypt sind die aktuellen Best Practices. scrypt wird besser als bcrypt sein, aber es wurde von Linux / Unix oder von Webservern noch nicht als Standard akzeptiert, und es wurden noch keine eingehenden Reviews zu seinem Algorithmus veröffentlicht. Dennoch sieht die Zukunft des Algorithmus vielversprechend aus. Wenn Sie mit Ruby arbeiten, gibt es ein scrypt-Juwel , das Ihnen helfen wird, und Node.js hat jetzt sein eigenes scrypt Paket. Sie können Scrypt in PHP entweder über die Scrypt Erweiterung oder die Libsodium Erweiterung verwenden (beide sind in PECL verfügbar).

Ich empfehle sehr, die Dokumentation für die crypt-Funktion zu lesen, wenn Sie verstehen möchten, wie Sie bcrypt verwenden, oder sich selbst einen good wrapper oder etwas wie openwall.com/phpass für eine ältere Implementierung verwenden. Ich empfehle mindestens 12 Runden bcrypt, wenn nicht 15 bis 18.

Ich änderte meine Meinung über die Verwendung von bcrypt, als ich erfuhr, dass bcrypt nur den Schlüsselplan von Blowfish mit einem variablen Kostenmechanismus verwendet. Mit letzterem können Sie die Kosten erhöhen, um ein Passwort zu erzwingen, indem Sie den bereits teuren Schlüsselplan von blowfish erhöhen.

Durchschnittliche Praxis

Ich kann mir diese Situation fast nicht mehr vorstellen. openwall.com/phpass unterstützt PHP 3.0.18 bis 5.3, sodass es auf fast jeder vorstellbaren Installation verwendet werden kann - und sollte verwendet werden, wenn Sie nicht sicher sind, dass Ihre Umgebung bcrypt unterstützt.

Angenommen, Sie können bcrypt oder PHPASS überhaupt nicht verwenden. Was dann?

Versuchen Sie eine Implementierung von PDKBF2 mit der maximalen Anzahl an Runden , die Ihre Umgebung / Anwendung / Benutzerwahrnehmung tolerieren kann. Die niedrigste Zahl, die ich empfehlen würde, ist 2500 Runden. hash_hmac() sicher, dass Sie hash_hmac() wenn es verfügbar ist, damit die Operation schwieriger zu reproduzieren ist.

Zukunftspraktiken

In PHP 5.5 gibt es eine vollständige Passwortschutz-Bibliothek , die jegliche Probleme bei der Arbeit mit bcrypt abstrahiert. Während die meisten von uns mit PHP 5.2 und 5.3 in den meisten gängigen Umgebungen, insbesondere Shared Hosts, beschäftigt sind, hat @ircmaxell eine Kompatibilitätsebene für die kommende API erstellt, die abwärtskompatibel zu PHP 5.3.7 ist.

Kryptographie-Zusammenfassung und Haftungsausschluss

Die erforderliche Rechenleistung, um ein Hash-Passwort tatsächlich zu knacken, existiert nicht. Die einzige Möglichkeit für Computer, ein Kennwort zu knacken, besteht darin, es neu zu erstellen und den Hash-Algorithmus zu simulieren, mit dem es gesichert wird. Die Geschwindigkeit des Hashes hängt linear mit seiner Fähigkeit zusammen, brutal zu sein. Schlimmer noch, die meisten Hash-Algorithmen können leicht parallelisiert werden, um noch schneller zu arbeiten. Deshalb sind kostspielige Systeme wie bcrypt und scrypt so wichtig.

Sie können möglicherweise nicht alle Bedrohungen oder Angriffswege voraussehen, und Sie müssen sich daher nach besten Kräften bemühen, Ihre Benutzer im Voraus zu schützen. Wenn Sie das nicht tun, verpassen Sie vielleicht sogar die Tatsache, dass Sie angegriffen wurden, bis es zu spät ist ... und Sie haften dafür . Um diese Situation zu vermeiden, handeln Sie zunächst paranoid. Greifen Sie Ihre eigene Software (intern) an und versuchen Sie, Benutzeranmeldeinformationen zu stehlen oder die Konten anderer Benutzer zu ändern oder auf deren Daten zuzugreifen. Wenn Sie die Sicherheit Ihres Systems nicht testen, können Sie niemanden beschuldigen außer sich selbst.

Zu guter Letzt: Ich bin kein Kryptograph. Was auch immer ich gesagt habe, ist meine Meinung, aber ich glaube, dass es auf gutem gesunden Menschenverstand basiert ... und viel Lesen. Denken Sie daran, seien Sie so paranoid wie möglich, machen Sie es so schwer wie möglich zu stören, und kontaktieren Sie dann, wenn Sie sich Sorgen machen, einen White-Hat-Hacker oder Kryptograph, um zu sehen, was sie über Ihren Code / Ihr System sagen.


Ab PHP 5.5 bietet PHP einfache, sichere Funktionen zum Hashing und Verifizieren von Passwörtern, php.net/manual/en/function.password-hash.php und password_verify

$password = 'anna';
$hash = password_hash($password, PASSWORD_DEFAULT);
$expensiveHash = password_hash($password, PASSWORD_DEFAULT, array('cost' => 20));

password_verify('anna', $hash); //Returns true
password_verify('anna', $expensiveHash); //Also returns true
password_verify('elsa', $hash); //Returns false

Wenn password_hash() verwendet wird, erzeugt es einen zufälligen Salt und fügt ihn in den ausgegebenen Hash ein (zusammen mit den verwendeten Kosten und dem Algorithmus). password_verify() liest dann diesen Hash und bestimmt die verwendete Salz- und Verschlüsselungsmethode und verifiziert sie das bereitgestellte Klartext-Passwort.

Durch die PASSWORD_DEFAULT PHP angewiesen, den Standard-Hashing-Algorithmus der installierten PHP-Version zu verwenden. Genau welcher Algorithmus das heißt, soll sich in zukünftigen Versionen im Laufe der Zeit ändern, so dass er immer einer der stärksten verfügbaren Algorithmen sein wird.

Steigende Kosten (standardmäßig 10) machen den Hash zu Brute-Force, aber das bedeutet auch, dass das Generieren von Hashes und das Verifizieren von Passwörtern für sie mehr Arbeit für die CPU Ihres Servers bedeutet.

Beachten Sie, dass sich alte Hashwerte auch dann noch gut verifizieren können, wenn der Standard-Hashing-Algorithmus sich ändert, da der verwendete Algorithmus im Hash gespeichert ist und password_verify() übernimmt.


Eine viel kürzere und sicherere Antwort - schreiben Sie nicht Ihren eigenen Passwort-Mechanismus überhaupt , verwenden Sie einen bewährten Mechanismus.

Die meisten Programmierer haben einfach nicht die Erfahrung, kryptografischen Code sicher zu schreiben, ohne Sicherheitslücken einzugehen.

Schneller Selbsttest: Was ist Passwort-Stretching und wie viele Iterationen sollten Sie verwenden? Wenn Sie die Antwort nicht kennen, sollten Sie password_hash() , da das Password-Stretching aufgrund der viel schnelleren CPUs und der Verwendung von GPUs und FPGAs für das Crawlen von Passwörtern mit einer Rate von Milliarden von Raten pro Sekunde eine entscheidende Funktion des Passwortmechanismus ist (mit GPUs).

Zum Beispiel können Sie alle 8-stelligen Windows-Passwörter in 6 Stunden knacken, indem Sie 25 GPUs verwenden, die auf 5 Desktop-PCs installiert sind. Dies ist Brute-Forcing, dh das Aufzählen und Überprüfen jedes Windows-Kennworts mit 8 Zeichen , einschließlich Sonderzeichen, und kein Wörterbuchangriff. Das war 2012, ab 2018 könnten Sie weniger GPUs verwenden oder mit 25 GPUs schneller knacken.

Es gibt auch viele Rainbow-Table-Angriffe auf Windows-Passwörter, die auf gewöhnlichen CPUs laufen und sehr schnell sind. All dies ist darauf zurückzuführen, dass Windows seine Kennwörter auch unter Windows 10 immer noch nicht sättigt oder dehnt - machen Sie nicht denselben Fehler wie Microsoft!

Siehe auch:

  • ausgezeichnete Antwort mit mehr darüber, warum password_hash() oder phpass der beste Weg zu gehen.
  • guter Blog-Artikel mit empfohlenen "Arbeitsfaktoren" (Anzahl der Iterationen) für Hauptalgorithmen einschließlich bcrypt, scrypt und PBKDF2.

Google sagt, dass SHA256 für PHP verfügbar ist.

Sie sollten auf jeden Fall ein Salz verwenden. Ich würde empfehlen, zufällige Bytes zu verwenden (und sich nicht auf Zeichen und Zahlen zu beschränken). Wie immer, je länger Sie wählen, desto sicherer, langsamer wird es. 64 Bytes sollten in Ordnung sein, denke ich.


Ich habe hier ein perfektes Thema gefunden: https://crackstation.net/hashing-security.htm , ich wollte, dass du davon profitierst, hier ist Quellcode auch, der auch gegen zeitbasierten Angriff vorbeugt.

<?php
/*
 * Password hashing with PBKDF2.
 * Author: havoc AT defuse.ca
 * www: https://defuse.ca/php-pbkdf2.htm
 */

// These constants may be changed without breaking existing hashes.
define("PBKDF2_HASH_ALGORITHM", "sha256");
define("PBKDF2_ITERATIONS", 1000);
define("PBKDF2_SALT_BYTES", 24);
define("PBKDF2_HASH_BYTES", 24);

define("HASH_SECTIONS", 4);
define("HASH_ALGORITHM_INDEX", 0);
define("HASH_ITERATION_INDEX", 1);
define("HASH_SALT_INDEX", 2);
define("HASH_PBKDF2_INDEX", 3);

function create_hash($password)
{
    // format: algorithm:iterations:salt:hash
    $salt = base64_encode(mcrypt_create_iv(PBKDF2_SALT_BYTES, MCRYPT_DEV_URANDOM));
    return PBKDF2_HASH_ALGORITHM . ":" . PBKDF2_ITERATIONS . ":" .  $salt . ":" . 
        base64_encode(pbkdf2(
            PBKDF2_HASH_ALGORITHM,
            $password,
            $salt,
            PBKDF2_ITERATIONS,
            PBKDF2_HASH_BYTES,
            true
        ));
}

function validate_password($password, $good_hash)
{
    $params = explode(":", $good_hash);
    if(count($params) < HASH_SECTIONS)
       return false; 
    $pbkdf2 = base64_decode($params[HASH_PBKDF2_INDEX]);
    return slow_equals(
        $pbkdf2,
        pbkdf2(
            $params[HASH_ALGORITHM_INDEX],
            $password,
            $params[HASH_SALT_INDEX],
            (int)$params[HASH_ITERATION_INDEX],
            strlen($pbkdf2),
            true
        )
    );
}

// Compares two strings $a and $b in length-constant time.
function slow_equals($a, $b)
{
    $diff = strlen($a) ^ strlen($b);
    for($i = 0; $i < strlen($a) && $i < strlen($b); $i++)
    {
        $diff |= ord($a[$i]) ^ ord($b[$i]);
    }
    return $diff === 0; 
}

/*
 * PBKDF2 key derivation function as defined by RSA's PKCS #5: https://www.ietf.org/rfc/rfc2898.txt
 * $algorithm - The hash algorithm to use. Recommended: SHA256
 * $password - The password.
 * $salt - A salt that is unique to the password.
 * $count - Iteration count. Higher is better, but slower. Recommended: At least 1000.
 * $key_length - The length of the derived key in bytes.
 * $raw_output - If true, the key is returned in raw binary format. Hex encoded otherwise.
 * Returns: A $key_length-byte key derived from the password and salt.
 *
 * Test vectors can be found here: https://www.ietf.org/rfc/rfc6070.txt
 *
 * This implementation of PBKDF2 was originally created by https://defuse.ca
 * With improvements by http://www.variations-of-shadow.com
 */
function pbkdf2($algorithm, $password, $salt, $count, $key_length, $raw_output = false)
{
    $algorithm = strtolower($algorithm);
    if(!in_array($algorithm, hash_algos(), true))
        die('PBKDF2 ERROR: Invalid hash algorithm.');
    if($count <= 0 || $key_length <= 0)
        die('PBKDF2 ERROR: Invalid parameters.');

    $hash_length = strlen(hash($algorithm, "", true));
    $block_count = ceil($key_length / $hash_length);

    $output = "";
    for($i = 1; $i <= $block_count; $i++) {
        // $i encoded as 4 bytes, big endian.
        $last = $salt . pack("N", $i);
        // first iteration
        $last = $xorsum = hash_hmac($algorithm, $last, $password, true);
        // perform the other $count - 1 iterations
        for ($j = 1; $j < $count; $j++) {
            $xorsum ^= ($last = hash_hmac($algorithm, $last, $password, true));
        }
        $output .= $xorsum;
    }

    if($raw_output)
        return substr($output, 0, $key_length);
    else
        return bin2hex(substr($output, 0, $key_length));
}
?>

Ich möchte nur darauf hinweisen, dass PHP 5.5 eine Passwort-Hash-API enthält , die einen Wrapper um crypt() bereitstellt. Diese API vereinfacht die Hashing-, Verifying- und Rashashing-Funktion für Passwort-Hashes erheblich. Der Autor hat auch ein Kompatibilitäts-Paket (in Form einer einzelnen password.php-Datei, die Sie einfach verwenden müssen) für diejenigen veröffentlicht, die PHP 5.3.7 und höher verwenden und dieses sofort verwenden möchten.

Es unterstützt derzeit nur BCRYPT, aber es soll einfach um andere Passwort-Hashing-Techniken erweitert werden und da die Technik und die Kosten als Teil des Hashes gespeichert werden, werden Änderungen an Ihrer bevorzugten Hashing-Technik / Kosten die aktuellen Hashes, das Framework nicht ungültig machen wird automatisch die korrekte Technik / Kosten bei der Validierung verwenden. Es behandelt auch das Generieren eines "sicheren" Salzes, wenn Sie nicht explizit Ihr eigenes definieren.

Die API bietet vier Funktionen:

  • password_get_info() - gibt Informationen über den gegebenen Hash zurück
  • password_hash() - erstellt einen Passwort-Hash
  • password_needs_rehash() - prüft, ob der angegebene Hash mit den angegebenen Optionen übereinstimmt. Nützlich, um zu überprüfen, ob der Hash mit Ihrem aktuellen Technik- / Kostenschema übereinstimmt, so dass Sie bei Bedarf einen erneuten Hash erstellen können
  • password_verify() - überprüft, ob ein Passwort mit einem Hash übereinstimmt

Im Moment akzeptieren diese Funktionen die Passwortkonstanten PASSWORD_BCRYPT und PASSWORD_DEFAULT, die momentan auch synonym sind. Der Unterschied ist, dass PASSWORD_DEFAULT "in neueren PHP-Versionen geändert werden kann, wenn neuere, stärkere Hashing-Algorithmen unterstützt werden." Die Verwendung von PASSWORD_DEFAULT und password_needs_rehash () beim Anmelden (und ggf. beim erneuten Speichern) sollte sicherstellen, dass Ihre Hashes relativ robust gegenüber Brute-Force-Angriffen sind, mit wenig oder gar keiner Arbeit für Sie.

EDIT: Ich habe gerade gemerkt, dass dies in Robert Ks Antwort kurz erwähnt wird. Ich werde diese Antwort hier lassen, da ich denke, dass sie ein bisschen mehr Informationen darüber gibt, wie es funktioniert und wie einfach es für diejenigen ist, die Sicherheit nicht kennen.


Obwohl die Frage beantwortet wurde, möchte ich nur wiederholen, dass die für das Hashing verwendeten Salze zufällig und nicht wie die in der ersten Antwort vorgeschlagene E-Mail-Adresse sein sollten.

Weitere Erklärungen finden Sie unter http://www.pivotalsecurity.com/blog/password-hashing-salt-should-it-be-random/

Kürzlich hatte ich eine Diskussion darüber, ob mit zufälligen Bits gesalzene Passwort-Hashes sicherer sind als die mit erratbaren oder bekannten Salzen gesalzenen. Mal sehen: Wenn das System, das das Passwort speichert, kompromittiert ist, genauso wie das System, das das zufällige Salz speichert, hat der Angreifer Zugriff auf Hash sowie auf Salz, also ist es egal, ob das Salz zufällig ist oder nicht. Der Angreifer kann vorberechnete Rainbow-Tabellen erzeugen, um den Hash zu knacken. Hier kommt der interessante Teil - es ist nicht so trivial, vorberechnete Tabellen zu generieren. Nehmen wir ein Beispiel eines WPA-Sicherheitsmodells. Ihr WPA-Passwort wird tatsächlich niemals an den Wireless Access Point gesendet. Stattdessen wird es mit Ihrer SSID (dem Netzwerknamen - wie Linksys, Dlink usw.) gehashed. Eine sehr gute Erklärung dafür, wie das funktioniert, ist hier. Um das Passwort aus dem Hash zu holen, müssen Sie sowohl das Passwort als auch das Salz (Netzwerkname) kennen. Church of Wifi hat bereits Hashtabellen vorberechnet, die die Top 1000 SSIDs und ungefähr 1 Million Passwörter haben. Die Größe aller Tabellen beträgt ca. 40 GB. Wie Sie auf ihrer Website lesen können, hat jemand 15 FGPA-Arrays für 3 Tage verwendet, um diese Tabellen zu generieren. Unter der Annahme, dass das Opfer die SSID als "a387csf3" und das Passwort als "123456" verwendet, wird es von diesen Tabellen geknackt werden? Nein! .. es kann nicht. Auch wenn das Kennwort schwach ist, haben die Tabellen keine Hashes für die SSID a387csf3. Das ist die Schönheit, zufälliges Salz zu haben. Es wird Cracker aufhalten, die auf vorberechneten Tabellen gedeihen. Kann es einen entschlossenen Hacker aufhalten? Wahrscheinlich nicht. Aber zufällige Salze bieten eine zusätzliche Verteidigungsschicht. Während wir uns mit diesem Thema befassen, wollen wir uns über den zusätzlichen Vorteil der Speicherung von Zufallssalzen auf einem separaten System unterhalten. Szenario 1: Passwort Hashes werden auf System X gespeichert und Salt Werte für Hashing werden auf System Y gespeichert. Diese Salt Werte sind erraten oder bekannt (zB Benutzername) Szenario 2: Password Hashes werden auf System X gespeichert und Salz Werte verwendet für Hashing wird auf System Y gespeichert. Diese Salzwerte sind zufällig. Falls System X kompromittiert wurde, wie Sie sich vorstellen können, ist es ein großer Vorteil, zufälliges Salz auf einem separaten System zu verwenden (Szenario 2). Der Angreifer muss zusätzliche Werte erraten, um Hashes knacken zu können. Wenn ein 32-Bit-Salz verwendet wird, können 2 ^ 32 = 4,294,967,296 (etwa 4,2 Milliarden) Iterationen für jedes erratene Passwort erforderlich sein.


SHA1 and a salt should suffice (depending, naturally, on whether you are coding something for Fort Knox or a login system for your shopping list) for the foreseeable future. If SHA1 isn't good enough for you, use SHA256 .

The idea of a salt is to throw the hashing results off balance, so to say. It is known, for example, that the MD5-hash of an empty string is d41d8cd98f00b204e9800998ecf8427e . So, if someone with good enough a memory would see that hash and know that it's the hash of an empty string. But if the string is salted (say, with the string " MY_PERSONAL_SALT "), the hash for the 'empty string' (ie " MY_PERSONAL_SALT ") becomes aeac2612626724592271634fb14d3ea6 , hence non-obvious to backtrace. What I'm trying to say, that it's better to use any salt, than not to. Therefore, it's not too much of an importance to know which salt to use.

There are actually websites that do just this - you can feed it a (md5) hash, and it spits out a known plaintext that generates that particular hash. If you would get access to a database that stores plain md5-hashes, it would be trivial for you to enter the hash for the admin to such a service, and log in. But, if the passwords were salted, such a service would become ineffective.

Also, double-hashing is generally regarded as bad method, because it diminishes the result space. All popular hashes are fixed-length. Thus, you can have only a finite values of this fixed length, and the results become less varied. This could be regarded as another form of salting, but I wouldn't recommend it.


I usually use SHA1 and salt with the user ID (or some other user-specific piece of information), and sometimes I additionally use a constant salt (so I have 2 parts to the salt).

SHA1 is now also considered somewhat compromised, but to a far lesser degree than MD5. By using a salt (any salt), you're preventing the use of a generic rainbow table to attack your hashes (some people have even had success using Google as a sort of rainbow table by searching for the hash). An attacker could conceivably generate a rainbow table using your salt, so that's why you should include a user-specific salt. That way, they will have to generate a rainbow table for each and every record in your system, not just one for your entire system! With that type of salting, even MD5 is decently secure.


ok in the fitsy we need salt salt must be unique so let generate it

   /**
     * Generating string
     * @param $size
     * @return string
     */
    function Uniwur_string($size){
        $text = md5(uniqid(rand(), TRUE));
        RETURN substr($text, 0, $size);
    }

also we need the hash I`m using sha512 it is the best and it is in php

   /**
     * Hashing string
     * @param $string
     * @return string
     */
    function hash($string){
        return hash('sha512', $string);
    }

so now we can use this functions to generate safe password

// generating unique password
$password = Uniwur_string(20); // or you can add manual password
// generating 32 character salt
$salt = Uniwur_string(32);
// now we can manipulate this informations

// hashin salt for safe
$hash_salt = hash($salt);
// hashing password
$hash_psw = hash($password.$hash_salt);

now we need to save in database our $hash_psw variable value and $salt variable

and for authorize we will use same steps...

it is the best way to safe our clients passwords...

Ps for last 2 steps you can use your own algorithm... but be sure that you can generate this hashed password in the future when you need to authorize user...





protection