Passwortbasierte Verschlüsselung: Die Komplettlösung

Passwort verschlüsseln: die kurze Antwort

Ein Passwort zu verschlüsseln ist meistens der falsche Weg. Ein Passwort, das Sie bei der Anmeldung nur prüfen müssen, gehört gehasht, mit bcrypt oder Argon2id und niemals verschlüsselt. Denn eine umkehrbare Speicherung liefert jedem Angreifer alle Klartextpasswörter, sobald der Schlüssel bekannt wird. Passwortbasierte Verschlüsselung ist für den anderen Fall da: Das Passwort öffnet Daten, die Sie später wieder lesen müssen.

Die richtige Antwort hängt also davon ab, was Sie tatsächlich vorhaben:

• Ein Anmeldepasswort speichern: mit Argon2id (19 MiB Speicher, 2 Iterationen) oder bcrypt (Kostenfaktor 10 oder höher) hashen. Das ursprüngliche Passwort lässt sich nicht zurückgewinnen, und genau das ist der Zweck.
• Daten mit einem Passwort schützen: einen Schlüssel aus dem Passwort ableiten (PBKDF2-HMAC-SHA256 oder Argon2id) und mit AES-256-GCM verschlüsseln. Der Nutzer merkt sich ein einziges Geheimnis und kann die Daten später trotzdem lesen.
• Ein Geheimnis an jemand anderen senden: die Datei oder Nachricht mit einem vorher vereinbarten Passwort verschlüsseln und den Chiffretext über einen beliebigen Kanal schicken.

Passwortbasierte Verschlüsselung: was sie ist und wann sie passt

Passwortbasierte Verschlüsselung leitet aus einem Passwort einen Schlüssel ab und verschlüsselt damit die Daten – das Passwort allein genügt, um den Klartext wiederherzustellen. Das ist das Gegenteil von Hashing: Ein Hash ist einseitig und belegt nur, dass ein Wert übereinstimmt.

Daraus folgt eine einfache Regel. Wenn Sie die Daten später wieder lesen müssen – Backup, Export, eine Datei für Dritte – brauchen Sie passwortbasierte Verschlüsselung mit einer echten Schlüsselableitung (PBKDF2, Argon2 oder scrypt) und einer authentifizierten Chiffre wie AES-256-GCM. Wenn Sie nur einen Login prüfen, brauchen Sie einen Passwort-Hash wie bcrypt – und niemals Verschlüsselung.

Der Datenbank-Leak

2023 wurden über 6 Milliarden Datensätze in Datenlecks offengelegt. Passwort-Hashing allein reicht nicht – was ist mit den verschlüsselten Daten?

Hashing vs. Verschlüsselung: Der entscheidende Unterschied

Hashing ist einseitig – geeignet für Passwortspeicherung. Verschlüsselung ist zweiseitig – geeignet für Daten, die wieder lesbar sein müssen. Verstehen Sie, wann Sie was einsetzen.

Den richtigen Algorithmus wählen

PBKDF2 mit 100.000+ Iterationen für Schlüsselableitung. AES-256-GCM für die Verschlüsselung selbst. SHA-256 für Datenintegrität. Diese Kombination bietet Schutz auf höchstem Niveau.

Implementierungsleitfaden

(1) Generieren Sie einen zufälligen Salt. (2) Leiten Sie den Schlüssel mit PBKDF2 ab. (3) Generieren Sie einen zufälligen IV. (4) Verschlüsseln Sie mit AES-256-GCM. (5) Speichern Sie Salt, IV und Chiffretext sicher.

Häufige Fehler bei der Passwortspeicherung

Verwendung von MD5/SHA-1, fest kodierte Salts, zu wenige PBKDF2-Iterationen, Wiederverwendung von IVs und Speicherung von Schlüsseln zusammen mit verschlüsselten Daten sind kritische Sicherheitsfehler.

bcrypt im Detail: Kostenfaktor, Salt und die 72-Byte-Grenze

Der Kostenfaktor von bcrypt gibt an, wie oft die Schlüsselaufbereitung wiederholt wird, und zwar in Zweierpotenzen: Faktor 12 bedeutet 4096 Runden. OWASP nennt für bcrypt einen Faktor von mindestens 10 und empfiehlt, ihn so hoch zu setzen, dass eine Prüfung unter einer Sekunde bleibt. Zu hohe Werte kosten auch Ihren Anmeldeendpunkt spürbar Zeit.

Der Salt steckt im Ergebnis selbst, eine zweite Spalte in der Datenbank ist nicht nötig. Eine Ausgabe sieht so aus: `$2b$12$...`. Die Segmente benennen Variante, Kostenfaktor und Salt. Weil der Faktor im String steht, lässt er sich später erhöhen, ohne alte Hashes zu entwerten: Beim nächsten Login wird der Hash mit dem neuen Faktor berechnet.

Wichtig ist die Eingabegrenze von 72 Bytes. Alles danach wird ignoriert, ein 100 Zeichen langes Passwort ist damit nicht stärker als ein 72 Byte langes. Wollen Sie längere Passwörter zulassen, verdichten Sie sie vorher mit einem HMAC auf eine feste Länge, etwa `bcrypt(base64(HMAC-SHA-384(Passwort, Pepper)), Salt, Kosten)`. Ein reines SHA-256-Vor-Hashing ist riskant, weil derselbe Passwort-Hash an anderer Stelle bereits aufgetaucht sein kann.

Passwortbasierte Verschlüsselung Schritt für Schritt

Verschlüsselung braucht andere Zutaten als Hashing: einen abgeleiteten Schlüssel, eine Nonce und eine authentifizierte Chiffre. Diese Reihenfolge hat sich bewährt:

1. Salt erzeugen: 16 Zufallsbytes über `crypto.getRandomValues`. Der Salt ist öffentlich und wird neben dem Chiffretext abgelegt.
2. Schlüssel ableiten: PBKDF2-HMAC-SHA256 mit dem Salt und einer Iterationszahl, die auf Ihrer Hardware etwa 100 bis 300 Millisekunden kostet.
3. Nonce erzeugen: 12 Zufallsbytes, für jeden Vorgang neu. Bei AES-GCM mit 96-Bit-Nonce wird sie direkt in den Zählerblock eingesetzt.
4. Verschlüsseln: `crypto.subtle.encrypt({ name: 'AES-GCM', iv }, key, data)`. Die Authentifizierung des Chiffretexts entsteht dabei mit.
5. Verpacken: Salt, IV und Chiffretext in eine Struktur schreiben, etwa `[Salt 16 | IV 12 | Chiffretext | Auth-Tag 16]`, und base64- oder hex-kodiert ablegen.

Iterationszahl, Parameter und Fehlersuche beim Entschlüsseln

Die Iterationszahl ist ein Kompromiss. OWASP nennt für serverseitiges PBKDF2-HMAC-SHA256 600.000 Iterationen; in einem Browser würden Sie bei jeder Passworteingabe mehrere Sekunden warten. Das Werkzeug auf dieser Seite arbeitet mit 100.000 Iterationen und einem 32-Byte-Schlüssel; die Werte sind fest konfiguriert und erscheinen in den Metadaten neben Salt, IV und Auth-Tag.

Zum Entschlüsseln brauchen Sie genau dieselben Parameter. Weichen Iterationszahl, Salt, IV oder Auth-Tag ab, scheitert die GCM-Prüfung und die Funktion meldet einen Fehler, ohne zu sagen, welcher Wert falsch war. Prüfen Sie deshalb zuerst, ob die Eingabe ein vollständiger Container ist, bevor Sie ein falsches Passwort vermuten.

• Auth-Tag: 16 Bytes, wird beim Entschlüsseln geprüft und nie mit dem Passwort verglichen
• Ausgabeformat: hex nur bei gerader Zeichenzahl, sonst base64, damit keine Bytes aus dem falschen Alphabet dekodiert werden

Verfahren nach Verwendungszweck wählen

Für Zugangsdaten und für Daten, die wieder lesbar sein müssen, gelten unterschiedliche Empfehlungen. OWASP sortiert die Verfahren so:

• Argon2id ist die erste Wahl: mindestens 19 MiB Speicher, 2 Iterationen, Parallelität 1
• scrypt, wenn Argon2id fehlt: N = 2^17, Blockgröße 8, Parallelität 1
• bcrypt bleibt für Bestandssysteme: Faktor 10 oder höher, Passwörter auf 72 Bytes begrenzt
• PBKDF2-HMAC-SHA256, wenn FIPS-140 gefordert ist: 600.000 Iterationen
• MD5, SHA-1 und reines SHA-256 sind für Passwörter ungeeignet, weil sie auf Geschwindigkeit ausgelegt sind

FAQ

Referenzen

Die Empfehlungen für Projekte im Jahr 2026 bleiben stabil: AES-256-GCM für Verschlüsselung mit einer neuen 96-Bit-Zufallsnonce pro Vorgang, SHA-256 oder SHA-512 für Hashing und RSA-OAEP oder ECDH für den Schlüsselaustausch. Halten Sie private Schlüssel mit crypto.subtle.importKey nicht extrahierbar, damit sie im Schlüsselspeicher des Browsers bleiben.

AES-256-GCM (oder ChaCha20-Poly1305) für symmetrische Nutzdaten verwenden – niemals ECB, niemals unauthentifiziertes CBC

• OWASP Password Storage Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
• NIST SP 800-63B – Digital Identity Guidelines: Authentication: https://pages.nist.gov/800-63-3/sp800-63b.html