PHP 8.4.2 Released!

Sicheres Hashing von Passwörtern

Dieser Absatz erklärt, warum Hash Funktionen zur sicheren Passwortspeicherung benutzt werden, und wie dies am effektivsten bewerkstelligt werden kann.

Warum sollten von Benutzern eingebene Passwörter gehasht werden?

Das Hashing von Passwörtern ist eine der grundlegendsten Sicherheitsüberlegungen, die beim Design aller Anwendungen oder Dienste, die Passwörter von Benutzern akzeptieren, angestellt werden muss. Ohne Hashing können im Falle eines erfolgreichen Angriffs auf den Datenspeicher alle gespeicherten Passwörter gestohlen und sofort verwendet werden, um nicht nur die Anwendung oder den Dienst zu kompromittieren, sondern auch die Konten von Benutzern bei anderen Diensten, wenn diese keine eindeutigen Passwörter verwenden.

Wenn Benutzer-Passwörter vor dem Abspeichern in der Datenbank gehasht werden, wird es für einen Angreifer sehr schwer, das Originalpasswort herauszufinden, während es gleichzeitig immer noch möglich ist, den resultierenden Hash mit dem Originalpasswort zu vergleichen.

Es ist jedoch wichtig zu beachten, dass das Hashing von Passwörtern nur davor schützt, dass sie im Datenspeicher kompromittiert werden, aber nicht unbedingt davor, dass sie durch bösartigen Code, der in die Anwendung oder den Dienst selbst eingeschleust wird, abgefangen werden können.

Warum sind verbreitete Hashfunktionen wie md5() und sha1() nicht für die Speicherung von Passwörtern geeignet?

Hash-Algorithmen wie MD5, SHA1 und SHA256 sind auf Geschwindigkeit und Effizienz optimiert. Mit modernen Techniken und leistungsstarker Hardware ist es aber trivial geworden, diese Hash-Algorithmen mit Brute-Force-Attacken anzugreifen.

Aufgrund der Geschwindigkeit, mit der ein moderner Computer diese Hash-Algorithmen umkehren kann, raten viele Sicherheitsexperten dringend davon ab, sie zum Hashing von Passwörtern zu verwenden.

Wie sollten Passwörter gehasht werden, wenn die üblichen Hashfunktionen nicht geeignet sind?

Wenn es um das Hashen von Passwörtern geht müssen zwei wichtige Dinge bedacht werden: Der Berechnungsaufwand und das Salt. Wenn es länger dauert einen Hash zu berechnen, wird ein Brute Force Angriff stark verzögert.

PHP bietet eine native Passworthashing-API die sich auf eine sichere Art um das Hashen und Verifizieren von Passwörtern kümmert.

Der empfohlene Algorithmus für das Hashen von Passwörtern ist Blowfish, welcher auf als Standardalgorithmus von der Passwort Hashing API benutzt wird, da dieser einen signifikant höheren Berechnungsaufwand als MD5 oder SHA1 voraussetzt und trotzdem weiterhin skalierbar ist.

Die Funktion crypt() ist auch für das Hashing von Passwörtern verfügbar, wird aber nur für die Interoperabilität mit anderen Systemen empfohlen. Stattdessen wird dringend empfohlen, wann immer möglich die native Passwort-Hashing-API zu verwenden.

Was ist ein Salt?

Ein kryptografisches Salt sind Daten, die während des Hashens an das Passwort angefügt werden um die Möglichkeit des Angriffs über Rainbowtables zu erschweren. Rainbowtables sind bereits vorberechnete Paare (Schlüssel, Hash), die benutzt werden können, um für einen gegebenen Hash das vorberechnete Passwort nachzuschlagen.

Vereinfacht ausgedrückt ist ein Salt ein zusätzliches Datenelement, das das Knacken von Hashes erheblich erschwert. Es gibt Onlinedienste bei denen man für einen gegebenen Hash das dazugehörige Passwort herausfinden kann. Die Benutzung eines Salts macht es unpraktisch bis unmöglich das Passwort durch die Benutzung dieser Dienste zu finden.

Die Funktion password_hash() generiert ein zufälliges Salt, sollte beim Aufruf der Funktion keines übergeben werden. Dies ist generell der einfachste und sicherste Ansatz.

Wie werden Salts gespeichert?

Die Funktionen password_hash() oder crypt() geben den Salt als einen Teil des generierten Hashs zurück. Dieser Wert sollte unverändert abgespeichert werden, da er Informationen über den Hashalgorithmus enthält und direkt an die Funktion password_verify() übergeben werden kann um ein Passwort zu verifzieren.

Warnung

Um Timing-Angriffe zu vermeiden, sollte immer password_verify() verwendet werden, anstatt das Ergebnis erneut zu hashen und mit einem gespeicherten Hash zu vergleichen.

Das folgende Diagramm zeigt das Format eines Rückgabewertes der Funktionen crypt() oder password_hash(). Wie zu sehen ist, enthalten die Hashes alle Informationen über den Algorithmus und das Salt, die für die spätere Verifikation von Passwörtern benötigt werden.


        Die Komponenten des Rückgabewerten von password_hash und crypt in
        dieser Reihenfolge: Der verwendete Algorithmus, die Optionen des
        Algorithmus, das verwendete Salt und das gehashte Passwort.

add a note

User Contributed Notes 3 notes

up
147
alf dot henrik at ascdevel dot com
10 years ago
I feel like I should comment some of the clams being posted as replies here.

For starters, speed IS an issue with MD5 in particular and also SHA1. I've written my own MD5 bruteforce application just for the fun of it, and using only my CPU I can easily check a hash against about 200mill. hash per second. The main reason for this speed is that you for most attempts can bypass 19 out of 64 steps in the algorithm. For longer input (> 16 characters) it won't apply, but I'm sure there's some ways around it.

If you search online you'll see people claiming to be able to check against billions of hashes per second using GPUs. I wouldn't be surprised if it's possible to reach 100 billion per second on a single computer alone these days, and it's only going to get worse. It would require a watt monster with 4 dual high-end GPUs or something, but still possible.

Here's why 100 billion per second is an issue:
Assume most passwords contain a selection of 96 characters. A password with 8 characters would then have 96^8 = 7,21389578984e+15 combinations.
With 100 billion per second it would then take 7,21389578984e+15 / 3600 = ~20 hours to figure out what it actually says. Keep in mind that you'll need to add the numbers for 1-7 characters as well. 20 hours is not a lot if you want to target a single user.

So on essence:
There's a reason why newer hash algorithms are specifically designed not to be easily implemented on GPUs.

Oh, and I can see there's someone mentioning MD5 and rainbow tables. If you read the numbers here, I hope you realize how incredibly stupid and useless rainbow tables have become in terms of MD5. Unless the input to MD5 is really huge, you're just not going to be able to compete with GPUs here. By the time a storage media is able to produce far beyond 3TB/s, the CPUs and GPUs will have reached much higher speeds.

As for SHA1, my belief is that it's about a third slower than MD5. I can't verify this myself, but it seems to be the case judging the numbers presented for MD5 and SHA1. The issue with speeds is basically very much the same here as well.

The moral here:
Please do as told. Don't every use MD5 and SHA1 for hasing passwords ever again. We all know passwords aren't going to be that long for most people, and that's a major disadvantage. Adding long salts will help for sure, but unless you want to add some hundred bytes of salt, there's going to be fast bruteforce applications out there ready to reverse engineer your passwords or your users' passwords.
up
24
swardx at gmail dot com
8 years ago
A great read..

https://nakedsecurity.sophos.com/2013/11/20/serious-security-how-to-store-your-users-passwords-safely/

Serious Security: How to store your users’ passwords safely

In summary, here is our minimum recommendation for safe storage of your users’ passwords:

Use a strong random number generator to create a salt of 16 bytes or longer.
Feed the salt and the password into the PBKDF2 algorithm.
Use HMAC-SHA-256 as the core hash inside PBKDF2.
Perform 20,000 iterations or more. (June 2016.)
Take 32 bytes (256 bits) of output from PBKDF2 as the final password hash.
Store the iteration count, the salt and the final hash in your password database.
Increase your iteration count regularly to keep up with faster cracking tools.

Whatever you do, don’t try to knit your own password storage algorithm.
up
-2
tamas at microwizard dot com
3 years ago
While I am reading the comments some old math lessons came into my mind and started thinking. Using constants in a mathematical algorythms do not change the complexity of the algorythm itself.

The reason of salting is to avoid using rainbow tables (sorry guys this is the only reason) because it speeds up (shortcuts) the "actual" processing power.
(((Longer stored hashes AND longer password increases complexity of cracking NOT adding salt ALONE.)))

PHP salting functions returns all the needed information for checking passwords, therfore this information should be treated as constant from farther point of view. It is also a target for rainbow tables (sure: for much-much larger ones).

What is the solution?
The solution is to store password hash and salt on different places.
The implementation is yours. Every two different places will be good enough.

Yes, it will make problems for hackers. He/she needs to understand your system. No speed up for password cracking will work for him/her without reimplementing your whole system.

This is my two cent.
To Top