Was ist Passwort-Hashing und Salting?

Warum ist sicheres Speichern von Passwörtern so wichtig?

Passwörter gehen verloren – nicht beim Login, sondern wenn eine Datenbank in falsche Hände gerät. Ob Angreifer:innen dann sofort Zugriff auf Konten haben oder vor einer kaum lösbaren Aufgabe stehen, entscheidet die Art, wie die Passwörter gespeichert wurden. Passwort-Hashing und Salting sind dafür der Standard. Hier erfährst du, wie beide Verfahren funktionieren, welche Algorithmen heute empfohlen werden und wie du ein bestehendes System sicher umstellst.

Was ist Passwort-Hashing?

Beim Passwort-Hashing wird ein Passwort mithilfe einer Hashfunktion in eine Zeichenkette fester Länge umgewandelt. Diese Zeichenkette – der Hashwert – sieht völlig anders aus als das ursprüngliche Passwort und lässt sich nicht zurückrechnen. Gespeichert wird nur der Hashwert, nie das Passwort selbst. Typische Algorithmen dafür sind Argon2, scrypt und bcrypt.

Warum ist Passwort-Hashing notwendig?

1. Schutz bei Datenlecks

Wird eine Datenbank kompromittiert, in der Passwörter im Klartext liegen, können Angreifer:innen sofort auf alle Konten zugreifen. Hashwerte dagegen sind unlesbar – und durch Salting sogar bei identischen Passwörtern unterschiedlich.

2. Einwegfunktion

Hashfunktionen sind nicht umkehrbar. Selbst der Betreiber einer Plattform kann das Originalpasswort nicht rekonstruieren. Das schützt Nutzer:innen auch vor Missbrauch durch Innentäter:innen oder kompromittierte Administratorkonten.

3. Stand der Technik und rechtliche Pflicht

Nach Art. 32 DSGVO müssen Unternehmen personenbezogene Daten mit geeigneten technischen und organisatorischen Maßnahmen (TOMs) nach dem Stand der Technik schützen. Zugangsdaten gehören dazu. Klartextpasswörter oder veraltete Verfahren wie MD5 entsprechen nicht dem Stand der Technik. Auch die ISO 27001 verlangt im Annex A (Control 5.17) einen sicheren Umgang mit Authentifizierungsinformationen.

Hashing vs. Verschlüsselung: Der Unterschied erklärt

Hashing und Verschlüsselung werden oft verwechselt, erfüllen aber unterschiedliche Zwecke. Verschlüsselung ist umkehrbar: Eine Nachricht wird mit einem Schlüssel verschlüsselt und kann später mit dem passenden Schlüssel wieder entschlüsselt werden. Ziel ist die Vertraulichkeit von Informationen, etwa bei der Übertragung.

Hashing dagegen ist nicht umkehrbar. Deshalb eignet es sich ideal zur Prüfung von Passwörtern: Beim Login wird das eingegebene Passwort erneut gehasht und mit dem gespeicherten Hash verglichen – ohne dass das Passwort selbst jemals gespeichert werden muss.

Kurz:

• Verschlüsselung = wiederherstellbar (z. B. für Datenübertragung)
• Hashing = Einwegfunktion (z. B. für Passwortprüfung)

Eigenschaften sicherer Hashfunktionen

Eine Hashfunktion für Passwörter muss andere Anforderungen erfüllen als eine Hashfunktion für Prüfsummen:

• Langsamkeit (Rechenintensität): erschwert Brute-Force-Angriffe
• Salt-Unterstützung: verhindert Angriffe mit Rainbow Tables
• Speicherhärte: erschwert Angriffe mit Grafikkarten (GPUs) und Spezialhardware
• Anpassbare Parameter: Rechenaufwand lässt sich mit steigender Rechenleistung erhöhen
• Gepflegter, geprüfter Algorithmus: aktiv weiterentwickelt und von der Fachwelt analysiert

Was ist ein Salt – und wofür wird er gebraucht?

Ein Salt ist eine zufällig erzeugte Zeichenfolge, die für jedes Passwort einzeln erzeugt und mit in den Hash einbezogen wird. Dadurch erzeugen auch identische Passwörter unterschiedliche Hashwerte. Ohne Salt könnten Angreifer:innen vorberechnete Tabellen (Rainbow Tables) nutzen, um Passwörter sofort zu erkennen. Mit Salt müssten sie für jeden einzelnen Hash neu rechnen. Der Salt muss nicht geheim sein und wird üblicherweise zusammen mit dem Hash gespeichert.

Beispiel:

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

Zusätzlicher Schutz durch einen Pepper: Ein Pepper ist ein geheimer Wert, der nicht in der Datenbank, sondern getrennt davon gespeichert wird, etwa in einem Hardware-Sicherheitsmodul oder Secrets Manager. Gelangt nur die Datenbank in falsche Hände, fehlt Angreifer:innen dieser Wert, um Passwörter zu knacken.

Empfohlene Algorithmen fürs Passwort-Hashing

Das Open Worldwide Application Security Project (OWASP) empfiehlt aktuell folgende Verfahren und Mindestwerte:

Auch das BSI empfiehlt in seiner Technischen Richtlinie TR-02102-1 seit 2020 Argon2id für die passwortbasierte Schlüsselableitung – also genau das Verfahren, auf dem sicheres Passwort-Hashing beruht. Die genannten Werte sind Mindestwerte: Wie hoch du sie ansetzt, hängt von der Leistung deiner Server und der akzeptablen Wartezeit beim Login ab.

Warum MD5 und SHA-1 unsicher sind

MD5 und SHA-1 wurden nicht für Passwörter, sondern für schnelle Integritätsprüfungen entwickelt. Genau das ist ihr Problem: Sie sind so schnell, dass Angreifer:innen mit einer einzigen Grafikkarte Milliarden Passwörter pro Sekunde durchprobieren können. Zudem gelten beide als kryptografisch gebrochen: Es gibt praktische Methoden, um Kollisionen zu erzeugen, also zwei verschiedene Eingaben mit identischem Hash. Für Passwörter sind sie deshalb völlig ungeeignet. Das gilt übrigens auch für SHA-256 ohne Salt und Work Factor: Der Algorithmus ist zwar nicht gebrochen, aber ebenfalls viel zu schnell.

So funktioniert die Passwortprüfung mit Hashes

Beim Login läuft die Prüfung so ab:

1. Die Nutzerin oder der Nutzer gibt das Passwort ein.
2. Das System liest den zugehörigen Salt und Hash aus der Datenbank.
3. Es hasht das eingegebene Passwort mit demselben Salt und denselben Parametern.
4. Das Ergebnis wird mit dem gespeicherten Hash verglichen.
5. Stimmen die Werte überein, ist die Anmeldung erfolgreich.

Das Passwort selbst wird dabei nie gespeichert – nur die Hashwerte entscheiden.

Warum Rechenintensität entscheidend ist

Die Rechenintensität (Work Factor) ist ein zentrales Sicherheitsmerkmal: Je mehr Rechenzeit und Speicher ein Hash benötigt, desto weniger Passwörter können Angreifer:innen pro Sekunde ausprobieren. Moderne Algorithmen wie Argon2id oder bcrypt lassen sich so einstellen, dass ein Hashvorgang einige Hundert Millisekunden dauert. Für Nutzer:innen beim Login ist das kaum spürbar – für Angreifer:innen, die Milliarden Kombinationen testen wollen, ist es ein massives Hindernis.

Wichtig: Überprüfe den Work Factor regelmäßig und erhöhe ihn, wenn die verfügbare Rechenleistung steigt.

Risiken durch unsichere Passwortspeicherung

Die größten Risiken sind:

• Kontoübernahme und Identitätsdiebstahl: Werden Klartextpasswörter geleakt, können Konten sofort übernommen werden.
• Credential Stuffing: Viele Menschen nutzen dasselbe Passwort für mehrere Dienste. Angreifer:innen testen geleakte Zugangsdaten automatisiert auf anderen Plattformen.
• Vertrauens- und Imageverlust: Ein Datenleck mit Klartextpasswörtern kann den Ruf eines Unternehmens langfristig beschädigen.
• DSGVO-Verstöße und Bußgelder: Unzureichend geschützte Passwörter sind ein Verstoß gegen Art. 32 DSGVO. Kommt es zu einem Leck, musst du es in der Regel binnen 72 Stunden der Aufsichtsbehörde melden – wie das geht, erklärt unser Leitfaden zum Melden einer Datenpanne.

So stellst du auf modernes Hashing um

Die Umstellung bestehender Systeme ist technisch anspruchsvoll, aber machbar:

1. Neues Verfahren einführen: z. B. Argon2id statt SHA-1 oder MD5.
2. Bestehende Hashes sofort absichern: Die alten Hashwerte werden mit dem neuen Verfahren erneut gehasht („Hash-Wrapping“). So ist die Datenbank sofort geschützt, ohne auf Logins zu warten.
3. Beim nächsten Login umstellen: Meldet sich jemand an, wird das Passwort direkt mit dem neuen Verfahren gehasht und der alte Wert ersetzt.
4. Hashes versionieren: Speichere zu jedem Hash das Verfahren und die Parameter. Die Standardformate von Argon2id (beginnt mit „argon2id“) und bcrypt (beginnt mit „2b“) enthalten diese Angaben bereits.
5. Optional: Passwortwechsel anregen: Bitte Nutzer:innen um ein neues Passwort, um die Migration zu beschleunigen – und biete idealerweise zusätzlich eine Zwei-Faktor-Authentifizierung an.

Wichtig ist, die Umstellung sauber zu testen, zu protokollieren und als Teil deiner TOMs zu dokumentieren.

Fazit

Passwort-Hashing und Salting sind keine Kür, sondern Pflicht: Nur so bleiben Zugangsdaten auch dann geschützt, wenn eine Datenbank in falsche Hände gerät. Setze für neue Systeme auf Argon2id, nutze für jedes Passwort einen eigenen Salt und überprüfe den Work Factor regelmäßig. MD5, SHA-1 und Klartextspeicherung haben in modernen Systemen nichts mehr verloren.

Noch sicherer wird es, wenn Passwörter gar nicht mehr die einzige Hürde sind. Welche Verfahren sich dafür eignen, zeigt unser Artikel zu sicheren Alternativen zu Passwörtern.

Sicheres Passwort-Hashing ist Teil deiner technischen und organisatorischen Maßnahmen nach DSGVO und ein Baustein jeder ISO-27001-Zertifizierung. Mit heyData dokumentierst du deine Sicherheitsmaßnahmen strukturiert und bist für Audits und Kundenanfragen vorbereitet.

Mach den ersten Schritt zu einer sauberen Sicherheitsdokumentation. Buche jetzt eine Demo!