Passwörter in der Datenbank speichern

Dieser Blogbeitrag richtet sich an Entwickler.

Jede Applikation mit Benutzern hat das Problem, dass die Passwörter der Benutzer in irgendeiner Form gespeichert werden müssen. Die schlechteste Idee dabei ist, dass Passwort als Klartext direkt in der Datenbank zu speichern.

Angriffe

Passwörter sollten selbst nach einem Datenleck oder einer vollständigen Kompromittierungen eines Systems noch sicher sein. Hat der Angreifer Zugriff auf den Source-Code und die Daten in der Datenbank, soll er dennoch nicht an die Klartext-Passwörter gelangen. Klar sind die Daten im betroffenen System dann ersichtlich. Da jedoch die Wiederverwendung von Passwörtern durch die Nutzer leider weit verbreitet ist, sollten wenigstens die Passwörter nicht ersichtlich sein.

Verschlüsseln vs hashen

Bei Passwörtern ist es jedoch auch nicht sinnvoll diese zu verschlüsseln. Verschlüsselter Text kann mit dem entsprechenden Schlüssel oder Private-Key entschlüsselt werden. Diese Anforderung ist bei Passwörtern nicht notwendig.

So hat sich etabliert, dass Passwörter mit einer One-Way-Funktion in einen Hash umgerechnet werden. Der Hash-Algorithmus stellt dabei sicher, dass man den Hash nicht in den ursprünglichen Text zurückrechnen kann.

Einige Basics

Wie kann eine Applikation nun prüfen, ob der Benutzer das richtige Passwort angegeben hat? Ganz einfach, anstatt das Passwort serverseitigen in den Klartext zu entschlüsseln und mit dem Passwort, welches der Benutzer angegeben hat zu vergleichen, wird das Klartextpasswort des Benutzers in den Hash umgerechnet und mit dem Passwort-Hash in der Datenbank verglichen.

Anstatt:

request.POST["password"] == encrypt(encryped_password_from_db)

Besser:

hash(request.POST["password"]) == password_hash_from_db

Hash-Algorithmen

Es gibt verschiedene Arten von Hash-Algorithmen. So ist zum Beispiel SHA-256 auf Geschwindigkeit und Effizienz ausgelegt und wurde für die Integritätsprüfung von Daten entwickelt. Für das Hashen von Passwörtern ist ein solcher Algorithmus jedoch nicht geeignet. Für das Hashen von Passwörtern sollte ein Hash verwendet werden, welcher so rechenintensiv (CPU und Memory) wie möglich ist. Der Server muss das Verfahren bei jedem Anmeldeversuch nur einmal anwenden, während Angreifer bei einem Bruteforce-Angriff es Milliarden Mal anwenden müsste.

Bruteforce-Angriff

Bei einem Bruteforce-Angriff werden ganze Wortlisten oder jedes mögliche Passwort durchprobiert.

Salt and Pepper

Rainbow-Tabellen sind vorgerechnete Hash-Listen. Mit diesen Listen entfällt das teure Neuberechnen der Hashes. Mit Rainbow-Tables können bei Data-Breaches die Passwort-Hashes sehr schnell in der Tabelle nachgeschaut werden, wenn das Passwort in der Rainbow-Tabelle vorhanden ist. Um dies zu verhindern werden die Passwörter vor dem Hashen mit einem Salt versehen./p>

hashed_password = hash(salt + password)

Dank diesem Mechanismus werden die Rainbow-Tabellen unbrauchbar gemacht und die Hashes müssen immer neu gerechnet werden.

Ein Pepper kann zusätzlich zum Salt verwendet werden, um einen zusätzlichen Sicherheitslayer zu schaffen. Damit soll verhindert werden, dass ein Angreifer einen der Hashes knacken kann, wenn er nur Zugriff auf die Datenbank hat (durch Ausnutzen einer SQL-Injection oder wenn er Zugriff auf ein Datenbank-Backup erlangt).

Eine Peppering-Strategien besteht darin, die Kennwörter wie üblich zu hashen (mit einem Passwort-Hashing-Algorithmus) und dann die Hashes mit einem symmetrischen Verschlüsselungsschlüssel zu verschlüsseln, bevor der Passwort-Hash in der Datenbank gespeichert wird, wobei der Schlüssel als Pepper fungiert. Peppering-Strategien haben keinerlei Auswirkungen auf die Passwort-Hashing-Funktion.

Welcher Hash-Algorithmus sollte verwendet werden?

OWASP gibt zurzeit folgende Empfehlung für Hash-Algorithmen an:

• Argon2id
• scrypt
• bcrypt
• PBKDF2

Weitere Informationen:
https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html

Hashing auf dem Client

Es gibt Entwickler, welche die Passwörter auf dem Client hashen und dann an den Server senden. Dies birgt jedoch die Gefahr von Replay-Angriffen. Bei Replay-Angriffen können gestohlene Hashes direkt verwendet werden, um an den Server zu senden, ohne dass man dabei das Klartext-Passwort kennen muss. Wird das Passwort auf dem Client gehasht, so gilt es ein Mechanismus, welcher Replay-Attacken verhindert, zu implementieren.

Standard-Einstellungen von verbreiteten Frameworks

• Laravel: Bcrypt
• Symfony: Bcrypt
• Django: PBKDF2