Was ist Passwort-Hashing und Salting?

Beim Passwort Hashing handelt es sich um einen Prozess, bei dem ein Passwort mithilfe einer sogenannten Hashfunktion in eine Zeichenkette fester Länge umgewandelt wird. Diese Zeichenkette – der sogenannte Hashwert – sieht völlig anders aus als das ursprüngliche Passwort und lässt sich (theoretisch) nicht zurückrechnen. Typische Algorithmen dafür sind z. B. bcrypt, scrypt oder Argon2.

‍1. Schutz bei Datenlecks

Wenn eine Datenbank komprimitiert wird und die Passwörter im Klartext gespeichert sind, kann jeder Angreifer sofort auf die Konten zugreifen. Hashes hingegen sind unlesbar – und durch zusätzliche Sicherheitsmechanismen wie Salting sogar individuell unterschiedlich, selbst bei identischen Passwörtern.

‍2. Einwegfunktion

Hashfunktionen sind nicht umkehrbar – das heißt, selbst der Betreiber der Plattform kann das Originalpasswort nicht rekonstruieren. Das ist ein wichtiges Prinzip des „Zero Knowledge“-Prinzips in der IT-Sicherheit.

‍1. Standart in der IT-Sicherheit

Das Hashing (in Kombination mit Salt und einem sicheren Algorithmus) ist ein anerkannter Best Practice-Standard und wird u. a. in der DSGVO und in Sicherheitsstandards wie ISO 27001 indirekt gefordert 

Hashing und Verschlüsselung werden oft verwechselt, erfüllen aber unterschiedliche Zwecke. Verschlüsselung ist ein reversibler Prozess – das bedeutet, dass ein Passwort oder eine Nachricht mit einem Schlüssel verschlüsselt und später mit dem passenden Schlüssel wieder entschlüsselt werden kann. Das Ziel ist die Vertraulichkeit der Information über eine bestimmte Zeit hinweg.

Hashing dagegen ist nicht umkehrbar. Ein gehashter Wert kann nicht sinnvoll in das ursprüngliche Passwort zurückgewandelt werden. Deshalb eignet sich Hashing ideal zur Verifizierung von Passwörtern: Beim Login wird das eingegebene Passwort erneut gehasht und mit dem gespeicherten Hash verglichen – ohne das Passwort selbst jemals speichern zu müssen.

Kurz:

• Verschlüsselung = wiederherstellbar (z. B. für Datenübertragung)
• Hashing = Einweg-Funktion (z. B. für Passwortverifikation)

Eine sichere Hashfunktion für Passwörter muss spezifische Anforderungen erfüllen:

• Langsamkeit (Rechenintensität): Um Brute-Force-Angriffe zu erschweren
• Salt-Unterstützung: Um Rainbow-Table-Angriffe zu verhindern
• Resistenz gegen parallele Verarbeitung: Verhindert effiziente GPU- oder ASIC-Angriffe
• Zukunftssicherheit: Algorithmus sollte aktiv gepflegt und sicherheitsgeprüft sein
• Speicherhärtung (bei Argon2): Erschwert Angriffe mit dedizierter Hardware

Ein Salt ist eine zufällig generierte Zeichenfolge, die zusätzlich zum Passwort in den Hash einfließt. Dadurch wird sichergestellt, dass auch identische Passwörter unterschiedliche Hashes erzeugen. Ohne Salt könnte ein Angreifer vorberechnete Hash-Wörterbuchtabellen (sogenannte Rainbow Tables) verwenden, um Passwörter sofort zu erkennen. Der Salt macht diese Methode praktisch nutzlos, da der Angreifer für jeden Hash und jeden Salt neu rechnen müsste.

Beispiel:

• Nutzer A & B verwenden beide „Passwort123“
• Ohne Salt: gleicher Hash → leicht angreifbar
• Mit Salt: völlig unterschiedliche Hashes → sicherer

Für sicheres Passwort-Hashing gelten heute insbesondere folgende Algorithmen als Best Practices:

• bcrypt: Weit verbreitet, gut getestet, unterstützt Salting und ist konfigurierbar in der Rechenzeit
• scrypt: Zusätzlich speicherintensiv → erschwert Angriffe mit spezialisierter Hardware
• Argon2: Gewinner des Password Hashing Competition (PHC), gilt aktuell als modernster Standard (besonders Argon2id)

Diese Algorithmen bieten Schutz gegen moderne Angriffe und können in der Konfiguration an Sicherheitsanforderungen angepasst werden.

MD5 und SHA-1 wurden ursprünglich nicht für Passwortsicherheit, sondern für schnelle Integritätsprüfungen konzipiert. Genau das ist ihr Problem: Sie sind viel zu schnell und damit ideal für Brute-Force- oder Dictionary-Attacken geeignet. Zudem sind beide Algorithmen heute kryptografisch gebrochen – das bedeutet, es gibt reale Methoden, um gezielt Kollisionen zu erzeugen, also zwei verschiedene Eingaben mit identischem Hash. Das macht sie nicht nur unsicher, sondern ist für Passwörter völlig ungeeignet.

Beim Login läuft die Überprüfung wie folgt ab:

1. Der Benutzer gibt sein Passwort ein.
2. Das System entnimmt aus der Datenbank den zugehörigen Salt und Hash.
3. Es hasht das eingegebene Passwort mit demselben Salt.
4. Das Ergebnis wird mit dem gespeicherten Hash verglichen.
5. Stimmen die Werte überein, ist die Authentifizierung erfolgreich.

Das eigentliche Passwort wird dabei nie gespeichert oder direkt verglichen – nur die Hashwerte entscheiden.

Rechenintensität (auch Work Factor genannt) ist ein Sicherheitsmerkmal: Je mehr Rechenzeit ein Hash benötigt, desto schwieriger ist es für Angreifer*innen, Millionen Hashes pro Sekunde auszuprobieren. Moderne Algorithmen wie bcrypt oder Argon2 lassen sich so konfigurieren, dass ein Hashvorgang z. B. 200 Millisekunden dauert. Für legitime Nutzer ist das kein Problem – aber für Angreifer, die Milliarden Passwörter testen wollen, ist es ein massives Hindernis.

Wichtig: Der Work Factor sollte regelmäßig überprüft und ggf. angepasst werden, wenn die Rechenleistung zunimmt.

Die größten Risiken sind:

• Kompletter Identitätsdiebstahl: Wenn Klartextpasswörter geleakt werden, können Accounts direkt übernommen werden.
• Credential Stuffing: Die gleichen Passwörter werden oft auf mehreren Plattformen verwendet – Angreifer testen sie automatisiert auf anderen Seiten.
• Image- und Vertrauensverlust: Ein Datenleck mit Klartextpasswörtern kann den Ruf eines Unternehmens langfristig ruinieren.
• DSGVO-Verstöße und Bußgelder: Fehlender Schutz personenbezogener Daten kann rechtliche Konsequenzen nach sich ziehen.

Die Umstellung ist technisch anspruchsvoll, aber machbar:

1. Neue Hashmethode implementieren (z. B. bcrypt statt SHA1)
2. Bestehende Passwörter zunächst weiter verwenden, aber:
3. Beim nächsten Login oder Passwort-Reset den neuen Hashalgorithmus anwenden
4. Optional: alle Nutzer zu Passwortänderung auffordern, um Migration zu beschleunigen
5. Ggf. Versionierung der Hashes einführen (z. B. Hash mit Prefix: $2y$ bei bcrypt)

Wichtig ist, die Umstellung transparent und sicher zu gestalten – inklusive Tests, Logging und ggf. Benachrichtigung der Nutzer.