SHA1 vs md5 vs SHA256: Welche für ein PHP-Login verwenden?

Ich mache ein PHP-Login und versuche zu entscheiden, ob ich SHA1 oder Md5 oder SHA256 verwenden soll, über die ich in einem anderen Artikel über Stackoverflow gelesen habe. Sind einige von ihnen sicherer als andere? Benutze ich für SHA1 / 256 immer noch ein Salz?

Ist dies auch eine sichere Möglichkeit, das Passwort als Hash in MySQL zu speichern?

function createSalt()
{
    $string = md5(uniqid(rand(), true));
    return substr($string, 0, 3);
}

$salt = createSalt();

$hash = sha1($salt . $hash);

Weder. Sie sollten verwenden bcrypt. Die von Ihnen erwähnten Hashes sind alle so optimiert, dass sie schnell und einfach für die Hardware geeignet sind. Daher haben das Knacken dieselben Eigenschaften. Wenn Sie keine andere Wahl haben, sollten Sie zumindest ein langes Salz verwenden und mehrmals erneut hacken.

Verwenden von bcrypt in PHP 5.5+

PHP 5.5 bietet neue Funktionen für das Passwort-Hashing . Dies ist der empfohlene Ansatz für die Kennwortspeicherung in modernen Webanwendungen.

// Creating a hash
$hash = password_hash($password, PASSWORD_DEFAULT, ['cost' => 12]);
// If you omit the ['cost' => 12] part, it will default to 10

// Verifying the password against the stored hash  
if (password_verify($password, $hash)) {
    // Success! Log the user in here.
}

Wenn Sie eine ältere Version von PHP verwenden , sollten Sie wirklich ein Upgrade durchführen . Bis dahin können Sie password_compat verwenden , um diese API verfügbar zu machen .

Bitte lassen Sie auch password_hash()das Salz für Sie erzeugen. Es wird ein CSPRNG verwendet .

Zwei Vorbehalte gegen bcrypt

1. Bcrypt schneidet jedes Passwort, das länger als 72 Zeichen ist, stillschweigend ab.
2. Bcrypt wird nach allen NULZeichen abgeschnitten .

( Proof of Concept für beide Vorbehalte hier.)

Sie könnten versucht sein, die erste Einschränkung zu beheben, indem Sie Ihre Kennwörter vorab ausführen, bevor Sie sie über bcrypt ausführen. Dies kann jedoch dazu führen, dass Ihre Anwendung kopfüber in die zweite ausgeführt wird.

Verwenden Sie anstelle eines eigenen Schemas eine vorhandene Bibliothek, die von Sicherheitsexperten geschrieben und / oder bewertet wurde.

• Zend\Crypt (Teil von Zend Framework) bietet BcryptSha
• PasswordLockähnelt, BcryptShaverschlüsselt aber auch die bcrypt-Hashes mit einer authentifizierten Verschlüsselungsbibliothek .

TL; DR - Verwenden Sie bcrypt .

Ich denke, die Verwendung von md5 oder sha256 oder eines für die Geschwindigkeit optimierten Hashs ist vollkommen in Ordnung und ich bin sehr neugierig zu hören, welche Rebuttle andere Benutzer haben könnten. Hier sind meine Gründe

1. Wenn Sie erlauben Benutzer , schwache Passwörter zu verwenden, wie Gott, Liebe, Krieg, Frieden dann nicht die Verschlüsselung Rolle , werden Sie immer noch der Benutzer werden , so dass in dem Kennwort eingeben nicht die Hash und diese Passwörter oft zum ersten Mal verwendet werden, so wird dies nicht gehen etwas mit Verschlüsselung zu tun haben.

2. Wenn Sie kein SSL verwenden oder kein Zertifikat haben, können Angreifer, die den Datenverkehr abhören, das Kennwort abrufen. Alle Versuche, mit Javascript oder Ähnlichem zu verschlüsseln, sind clientseitig und können leicht geknackt und überwunden werden. Wieder ist dies nicht alles mit Datenverschlüsselung auf Server - Seite zu tun haben , .

3. Brute - Force - Angriffe Vorteil schwache Passwörter nehmen und wieder , weil Sie dem Benutzer erlauben , die Daten eingeben , wenn Sie die Login - Beschränkung von 3 nicht haben oder sogar ein wenig mehr als das Problem wieder nicht alles mit Datenverschlüsselung zu tun hat.

4. Wenn Ihre Datenbank kompromittiert wird, wurde höchstwahrscheinlich alles kompromittiert, einschließlich Ihrer Hashing-Techniken, egal wie kryptisch Sie sie gemacht haben. Dies kann wiederum ein verärgerter XSS-Angriff oder eine SQL-Injection eines Mitarbeiters oder ein anderer Angriff sein, der nichts mit Ihrer Kennwortverschlüsselung zu tun hat.

Ich glaube, Sie sollten immer noch verschlüsseln, aber das einzige, was ich bei der Verschlüsselung sehen kann, ist zu verhindern, dass Personen, die bereits Zugriff auf die Datenbank haben oder diese irgendwie erhalten haben, das Passwort nur laut vorlesen. Wenn es sich um jemanden handelt, für den in der Datenbank keine Berechtigung besteht, müssen Sie sich größere Sorgen machen, weshalb Sony in Betracht gezogen wurde, weil ein verschlüsseltes Passwort alles einschließlich der Kreditkartennummern schützte. Alles, was es tut, ist, das eine Feld zu schützen, das es ist.

Der einzige reine Vorteil, den ich bei komplexen Verschlüsselungen von Passwörtern in einer Datenbank sehen kann, besteht darin, Mitarbeiter oder andere Personen, die Zugriff auf die Datenbank haben, daran zu hindern, nur die Passwörter vorzulesen. Wenn es sich also um ein kleines Projekt handelt oder um etwas, für das ich mich nicht zu sehr um die Sicherheit auf der Serverseite kümmern würde, würde ich mich mehr um die Sicherung von Dingen kümmern, die ein Client möglicherweise an den Server sendet, wie z. B. SQL-Injection, XSS-Angriffe oder eine Vielzahl anderer Möglichkeiten könnte kompromittiert werden. Wenn jemand anderer Meinung ist, freue ich mich darauf, zu lesen, wie ein superverschlüsseltes Passwort von Seiten des Clients ein Muss ist.

Der Grund, warum ich versuchen wollte, dies klar zu machen, ist, dass die Leute zu oft glauben, dass ein verschlüsseltes Passwort bedeutet, dass sie sich keine Sorgen darüber machen müssen, dass es kompromittiert wird, und dass sie aufhören, sich um die Sicherung der Website zu sorgen.

Wie Johannes Gorset betonte, erklärt der Beitrag von Thomas Ptacek von Matasano Security , warum einfache, universelle Hashing-Funktionen wie MD5, SHA1, SHA256 und SHA512 eine schlechte Wahl für das Hashing von Passwörtern sind .

Warum? Sie sind zu schnell - Sie können mit einem modernen Computer mindestens 1.000.000 MD5-Hashes pro Sekunde pro Kern berechnen, sodass Brute Force gegen die meisten Passwörter möglich ist. Und das ist viel weniger als ein GPU-basierter Cracking-Server-Cluster!

Das Salzen ohne Schlüsseldehnung bedeutet nur, dass Sie den Regenbogentisch nicht vorberechnen können. Sie müssen ihn ad hoc für dieses bestimmte Salz erstellen. Aber es wird die Dinge nicht wirklich schwieriger machen.

User @ Will sagt:

Alle reden darüber, als könnten sie über das Internet gehackt werden. Wie bereits erwähnt, macht es die Einschränkung von Versuchen unmöglich, ein Passwort über das Internet zu knacken, und hat nichts mit dem Hash zu tun.

Sie müssen nicht. Anscheinend haben sie im Fall von LinkedIn die allgemeine SQL-Injection-Schwachstelle verwendet , um die Login-DB-Tabelle abzurufen und Millionen von Passwörtern offline zu knacken.

Dann kehrt er zum Offline-Angriffsszenario zurück:

Die Sicherheit kommt wirklich ins Spiel, wenn die gesamte Datenbank kompromittiert wird und ein Hacker dann 100 Millionen Passwortversuche pro Sekunde gegen den md5-Hash ausführen kann. SHA512 ist ungefähr 10.000 Mal langsamer.

Nein, SHA512 ist nicht 10000-mal langsamer als MD5 - es dauert nur etwa doppelt so viel. Crypt / SHA512 hingegen ist ein ganz anderes Tier, das wie sein BCrypt-Gegenstück das Stretching von Schlüsseln durchführt , einen ganz anderen Hash mit einem eingebauten zufälligen Salz erzeugt und für die Berechnung zwischen 500 und 999999 Mal so viel benötigt (Dehnung ist abstimmbar).

SHA512 => aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d
Crypt/SHA512 => $6$rounds=5000$usesomesillystri$D4IrlXatmP7rx3P3InaxBeoomnAihCKRVQP22JZ6EY47Wc6BkroIuUUBOov1i.S5KPgErtP/EN5mcO.ChWQW21

Die Wahl für PHP ist also entweder Crypt / Blowfish (BCrypt), Crypt / SHA256 oder Crypt / SHA512. Oder zumindest Crypt / MD5 (PHK). Siehe www.php.net/manual/en/function.crypt.php

Verwenden Sie SHA256. Es ist nicht perfekt, wie SHA512es für einen schnellen Hash ideal wäre, aber von den Optionen ist es die definitive Wahl. Achten Sie bei jeder Hashing-Technologie darauf, den Hash für zusätzliche Sicherheit zu salzen.

Als zusätzliche Anmerkung, FRKT, zeigen Sie mir bitte, wo jemand leicht einen gesalzenen SHA256-Hash knacken kann. Ich bin wirklich sehr interessiert, das zu sehen.

Wichtige Bearbeitung:

In Zukunft bitte bcryptals gehärteten Hash verwenden. Weitere Informationen finden Sie hier .

Bearbeiten beim Salzen:

Verwenden Sie eine Zufallszahl oder einen Zufallsbyte-Stream usw. Sie können das eindeutige Feld des Datensatzes in Ihrer Datenbank auch als Salz verwenden. Auf diese Weise unterscheidet sich das Salz pro Benutzer.

Was Leute vermissen, ist, dass der Hacker, wenn er Zugriff auf die Datenbank hat, wahrscheinlich auch Zugriff auf die PHP-Datei hat, die das Passwort hasht, und diese wahrscheinlich einfach ändern kann, um ihm alle erfolgreichen Kombinationen von Benutzernamen und Passwort zu senden. Wenn er keinen Zugriff auf das Webverzeichnis hat, kann er jederzeit einfach ein Kennwort auswählen und dieses in die Datenbank schreiben. Mit anderen Worten, der Hash-Algorithmus ist weniger wichtig als die Systemsicherheit. Wenn Sie Anmeldeversuche auch dann einschränken, wenn Sie kein SSL verwenden, kann der Angreifer die Verbindung einfach abhören, um die Informationen abzurufen. Wenn Sie nicht möchten, dass der Algorithmus lange Zeit für die Berechnung benötigt (für Ihre eigenen Zwecke), sollte SHA-256 oder SHA-512 mit einem benutzerspezifischen Salt ausreichen.

Richten Sie als zusätzliche Sicherheitsmaßnahme ein Skript (Bash, Batch, Python usw.) oder ein Programm ein, geben Sie ihm einen unklaren Namen und lassen Sie es überprüfen, ob sich die Datei login.php geändert hat (Datums- / Zeitstempel überprüfen), und senden Sie Ihnen eine E-Mail wenn ja. Außerdem sollten wahrscheinlich alle Anmeldeversuche mit Administratorrechten protokolliert werden und alle fehlgeschlagenen Anmeldeversuche in der Datenbank protokolliert und die Protokolle per E-Mail an Sie gesendet werden.

Alle reden darüber, als könnten sie über das Internet gehackt werden. Wie bereits erwähnt, macht es die Einschränkung von Versuchen unmöglich, ein Passwort über das Internet zu knacken, und hat nichts mit dem Hash zu tun.

Das Salz ist ein Muss, aber die Komplexität oder die Mehrfachsalze spielen keine Rolle. Jedes Salz allein hindert den Angreifer daran, einen vorgefertigten Regenbogentisch zu verwenden. Ein eindeutiges Salz pro Benutzer hindert den Angreifer daran, eine neue Regenbogentabelle zu erstellen, die für Ihre gesamte Benutzerbasis verwendet werden kann.

Die Sicherheit kommt wirklich ins Spiel, wenn die gesamte Datenbank kompromittiert wird und ein Hacker dann 100 Millionen Passwortversuche pro Sekunde gegen den md5-Hash ausführen kann. SHA512 ist ungefähr 10.000 Mal langsamer. Ein komplexes Passwort mit der heutigen Leistung könnte mit md5 noch 100 Jahre dauern und mit SHA512 10.000-mal so lange dauern. Die Salze stoppen eine Bruteforce überhaupt nicht, da sie immer bekannt sein müssen. Wenn der Angreifer Ihre Datenbank heruntergeladen hat, war er wahrscheinlich sowieso in Ihrem System.

MD5 ist aufgrund von Kollisionsproblemen schlecht - zwei verschiedene Passwörter erzeugen möglicherweise dasselbe md-5.

Sha-1 wäre dafür ausreichend sicher. Der Grund, warum Sie die gesalzene sha-1-Version des Kennworts speichern, besteht darin, dass Sie als Benutzer das Kennwort des Benutzers nicht in der Datei behalten, das er möglicherweise mit den Servern anderer Personen verwendet. Welchen Unterschied macht es sonst?

Wenn der Hacker Ihre gesamte unverschlüsselte Datenbank auf irgendeine Weise stiehlt, verhindert ein gesalzenes Passwort nur, dass er sich für zukünftige Anmeldungen als Benutzer ausgibt - der Hacker verfügt bereits über die Daten.

Was nützt es dem Angreifer, den Hash-Wert zu haben, wenn Ihr Benutzer ein einfaches Passwort eingibt?

Und selbst wenn der Hacker mit zukünftiger Technologie eine Million sha-1-Schlüssel pro Sekunde für einen Brute-Force-Angriff generieren könnte, würde Ihr Server eine Million Anmeldungen pro Sekunde verarbeiten, damit der Hacker seine Schlüssel testen kann? Dies ist der Fall, wenn Sie den Hacker versuchen lassen, sich mit dem gesalzenen sha-1 anstelle eines Kennworts wie bei einer normalen Anmeldung anzumelden.

Die beste Wahl ist, schlechte Anmeldeversuche auf eine vernünftige Zahl zu beschränken - beispielsweise 25 - und dann den Benutzer für ein oder zwei Minuten auszuschalten. Wenn die kumulativen Anmeldeversuche von bady innerhalb von 24 Stunden 250 erreichen, schließen Sie den Kontozugriff und senden Sie eine E-Mail an den Eigentümer.

Hier ist der Vergleich zwischen MD5 und SHA1. Sie können eine klare Vorstellung davon bekommen, welches besser ist.

Verwenden Sie argon2i . Das Argon2 Passwort-Hashing-Funktion hat den Passwort-Hashing-Wettbewerb gewonnen.

Andere sinnvolle Optionen sind scrypt , bcrypt und PBKDF2 , wenn die Verwendung von argon2 nicht verfügbar ist . Wikipedia hat Seiten für diese Funktionen:

• https://en.wikipedia.org/wiki/Argon2
• http://en.wikipedia.org/wiki/Scrypt
• http://en.wikipedia.org/wiki/Bcrypt
• http://en.wikipedia.org/wiki/PBKDF2

MD5, SHA1 und SHA256 sind Message Digests, keine Passwort-Hashing-Funktionen. Sie sind für diesen Zweck nicht geeignet.

Der Wechsel von MD5 zu SHA1 oder SHA512 verbessert die Sicherheit der Konstruktion nicht so sehr. Das Berechnen eines SHA256- oder SHA512-Hashs ist sehr schnell. Ein Angreifer mit gängiger Hardware könnte immer noch zig Millionen (mit einer einzelnen CPU) oder sogar Milliarden (mit einer einzelnen GPU) Hashes pro Sekunde versuchen. Zu den guten Passwort-Hashing-Funktionen gehört ein Arbeitsfaktor, um Wörterbuchangriffe zu verlangsamen.

Hier ist ein Vorschlag für PHP-Programmierer: Lesen Sie die PHP-FAQ und verwenden Sie password_hash () .

Nehmen wir den nächsten Punkt an: Die Hacker stehlen unsere Datenbank einschließlich der Benutzer und des Passworts (verschlüsselt). Und die Hacker haben ein gefälschtes Konto mit einem Passwort erstellt, das sie kennen.

MD5 ist schwach, weil es kurz und beliebt ist und praktisch jede Hash-Generation ohne Passwort schwach gegen einen Wörterbuchangriff ist. Aber..

Nehmen wir also an, wir verwenden immer noch MD5 mit einem SALZ. Die Hacker kennen das SALZ nicht, aber sie kennen das Passwort eines bestimmten Benutzers. So können sie testen: ????? 12345 wobei 12345 das Kennwort ist und ????? ist das Salz. Die Hacker können früher oder später das SALZ erraten.

Wenn wir jedoch ein MD5 + SALT verwendet und MD5 angewendet haben, gibt es keine Möglichkeit, die Informationen wiederherzustellen. Ich wiederhole jedoch, MD5 ist immer noch kurz.

Nehmen wir zum Beispiel an, mein Passwort lautet: 12345. Das SALZ ist BILLCLINTON

md5: 827ccb0eea8a706c4c34a16891f84e7b

md5 mit dem Hash: 56adb0f19ac0fb50194c312d49b15378

mD5 mit dem Hash über md5: 28a03c0bc950decdd9ee362907d1798a Ich habe versucht, diesen Onlinedienst zu verwenden, und ich habe keinen gefunden, der ihn knacken konnte. Und es ist nur MD5! (kann wie heute sein, es wird knackbar sein, weil ich den md5 online generiert habe)

Wenn Sie übertreiben möchten, ist SHA256 mehr als genug, wenn es mit einem Salz und zweimal angewendet wird.

tldr MD5 (HASH + MD5 (Passwort)) = ok, aber kurz, SHA256 ist mehr als genug.

Eine MD5-Verschlüsselung ist eine der schlimmsten, da Sie den Code umdrehen müssen und er bereits entschlüsselt ist. Ich würde Ihnen den SHA256 empfehlen. Ich programmiere etwas länger und habe gute Erfahrungen gemacht. Unten wäre auch eine Verschlüsselung.

password_hash() example using Argon2i

<?php
echo 'Argon2i hash: ' . password_hash('rasmuslerdorf', PASSWORD_ARGON2I);
?>
The above example will output something similar to:

Argon2i hash: $argon2i$v=19$m=1024,t=2,p=2$YzJBSzV4TUhkMzc3d3laeg$zqU/1IN0/AogfP4cmSJI1vc8lpXRW9/S0sYY2i2jHT0