PBKDF2 erklärt: Die passwortbasierte Schlüsselableitungsfunktion, die deinen Tresor sichert

TL;DR

PBKDF2 (Password-Based Key Derivation Function 2) ist ein in RFC 2898 definierter Key-Stretching-Algorithmus. Er wendet eine pseudozufällige Funktion (normalerweise HMAC-SHA256) viele Male auf ein Passwort und ein Salz an und erzeugt einen abgeleiteten Schlüssel. Die Iterationszahl macht Brute-Force-Angriffe exponentiell teurer. OWASP empfiehlt ab 2026 600.000 Iterationen für SHA-256. AppVault verwendet PBKDF2 mit 600.000 Iterationen, einem pro Installation eindeutigen 128-Bit-Salz und umschließt den Ausgabeschlüssel mit einem Secure-Enclave-Schlüssel für hardwaregebundenen Schutz.

Jedes Mal, wenn du dein iPhone entsperrst, ein Passwort auf einer Website eingibst oder einen Dateitresor öffnest, verwandelt ein Stück Software dein Geheimnis in einen kryptografischen Schlüssel. Diese Transformation ist kein einfacher Hash. Es ist eine sorgfältig entworfene Funktion, die Brute-Force-Angriffe teuer macht. Die am weitesten verbreitete dieser Funktionen ist PBKDF2.

PBKDF2 steht für Password-Based Key Derivation Function 2. Sie ist in RFC 2898 (PKCS #5 v2.0) definiert und seit über zwei Jahrzehnten ein von NIST empfohlener Standard. Sie nimmt ein Passwort, ein Salz, eine Iterationszahl und eine gewünschte Schlüssellänge entgegen und erzeugt einen abgeleiteten Schlüssel, der für Verschlüsselung, Authentifizierung oder andere kryptografische Operationen verwendet werden kann.

Dieser Artikel erklärt, wie PBKDF2 funktioniert, warum direktes Hashing nicht ausreicht, welche Rolle Salze und Iterationszahlen spielen, die OWASP-Empfehlung von 600.000 Iterationen für SHA-256 ab 2026 und wie PBKDF2 im Vergleich zu modernen Alternativen wie Argon2id, bcrypt und scrypt dasteht. Außerdem wird beschrieben, wie AppVault PBKDF2 als Teil seines Verschlüsselungsstapels einsetzt.

Warum direktes Hashing scheitert

Wenn du ein Passwort nimmst und seinen SHA-256-Hash berechnest, erhältst du einen 256-Bit-Wert. Dieser Wert kann als Schlüssel verwendet werden. Das Problem ist die Geschwindigkeit. Eine moderne GPU kann Milliarden von SHA-256-Hashes pro Sekunde berechnen. Ein Angreifer mit einer einzigen Consumer-GPU kann jedes 8-stellige Kleinbuchstaben-Passwort in wenigen Minuten durchprobieren.

Direktes Hashing hat auch keinen eingebauten Schutz gegen Vorausberechnung. Ohne Salz erzeugt dasselbe Passwort immer denselben Hash. Angreifer können Rainbow Tables – vorberechnete Hash-Ketten – erstellen und den Hash nachschlagen, um das Passwort sofort zu ermitteln.

PBKDF2 löst beide Probleme. Es wiederholt den Hash tausende Male, sodass jeder Versuch rechenintensiv wird. Es benötigt ein Salz, sodass identische Passwörter unterschiedliche Schlüssel erzeugen. Die Kombination aus Iterationszahl und Salz verwandelt einen schnellen Hash in eine langsame, eindeutige Ableitung.

Wie PBKDF2 funktioniert

PBKDF2 basiert auf einer pseudozufälligen Funktion (PRF), typischerweise HMAC-SHA256 oder HMAC-SHA1. Der Algorithmus arbeitet wie folgt:

1. Passwort und Salz werden kombiniert.
2. Die PRF wird auf das Salz angewendet, das mit einem Blockzähler verkettet ist (für Schlüssellängen größer als die PRF-Ausgabe).
3. Die Ausgabe wird mit dem Ergebnis der vorherigen Iteration XOR-verknüpft (für die erste Iteration ist das vorherige Ergebnis die PRF-Ausgabe selbst).
4. Die Schritte 2–3 werden für die angegebene Anzahl von Iterationen wiederholt.
5. Die endgültige Ausgabe ist der abgeleitete Schlüssel.

Die Iterationszahl ist der kritische Parameter. Jede Iteration fügt einen festen Arbeitsaufwand hinzu. Wenn ein Angreifer ein Passwort testen will, muss er die gesamte Kette von Iterationen durchlaufen. Mit 600.000 Iterationen dauert ein einzelner Passwortversuch etwa 600.000 Mal länger als ein einzelner SHA-256-Hash.

Das Salz muss pro Benutzer oder pro Instanz eindeutig sein. Ein 128-Bit-Salz (16 Byte) ist das von NIST empfohlene Minimum. Das Salz wird zusammen mit dem abgeleiteten Schlüssel (oder in den Tresor-Metadaten) gespeichert, damit die Ableitung während der Authentifizierung wiederholt werden kann.

Die OWASP-Empfehlung 2026

OWASP veröffentlicht ein Password Storage Cheat Sheet, das Empfehlungen für Iterationszahlen verschiedener Schlüsselableitungsfunktionen gibt. Stand 2026 lautet die Empfehlung für PBKDF2-HMAC-SHA256 600.000 Iterationen. Für PBKDF2-HMAC-SHA1 werden 1.300.000 Iterationen empfohlen, da SHA1 eine 160-Bit-Ausgabe erzeugt und pro Iteration etwas schneller ist.

Diese Zahlen sind nicht willkürlich. Sie sind so kalibriert, dass ein einzelner Passwortversuch auf moderner Consumer-Hardware etwa 0,1 Sekunden dauert. Diese Verzögerung ist für einen legitimen Benutzer kaum spürbar, macht Brute-Force-Angriffe aber unerschwinglich langsam. Ein Angreifer mit einem Cluster aus 100 GPUs kann nur ein paar hundert Passwörter pro Sekunde testen, nicht Milliarden.

Die Iterationszahl sollte im Laufe der Zeit erhöht werden, wenn die Hardware leistungsfähiger wird. OWASP aktualisiert seine Empfehlungen regelmäßig. AppVault verwendet 600.000 Iterationen für PBKDF2-HMAC-SHA256 und entspricht damit der Richtlinie von 2026.

Abwägungen bei der Iterationszahl

Höhere Iterationszahlen erschweren Brute-Force-Angriffe, erhöhen aber auch die Zeit, die zur Schlüsselableitung auf dem legitimen Gerät benötigt wird. Auf einem iPhone dauern 600.000 Iterationen von HMAC-SHA256 etwa 0,2 Sekunden. Das ist für das Entsperren des Tresors akzeptabel. Würde die Iterationszahl auf 10 Millionen erhöht, läge die Entsperrzeit bei über 3 Sekunden – das beeinträchtigt die Benutzererfahrung.

Es gibt auch einen Kompromiss beim Stromverbrauch. Mobile Geräte haben eine begrenzte Akkulaufzeit. Jede Iteration verbraucht CPU-Zyklen. AppVault balanciert Sicherheit und Benutzerfreundlichkeit aus, indem es eine Iterationszahl wählt, die starken Schutz bietet, ohne den Akku zu leeren oder den Benutzer zu frustrieren.

Ein weiterer Kompromiss ist der Speicherverbrauch. PBKDF2 ist nicht speicherhärtend. Es verwendet unabhängig von der Iterationszahl eine kleine, feste Menge Speicher. Dadurch ist es anfällig für GPU- und ASIC-Angriffe, die viele Passwortversuche parallelisieren können. Speicherhärtende Funktionen wie Argon2id und scrypt benötigen pro Versuch eine große Menge Speicher, was parallele Angriffe erheblich teurer macht. PBKDF2 gleicht seine fehlende Speicherhärte durch eine hohe Iterationszahl und – im Fall von AppVault – durch Hardwarebindung mittels Secure Enclave aus.

PBKDF2 vs. Argon2id, bcrypt und scrypt

PBKDF2 ist nicht die einzige passwortbasierte Schlüsselableitungsfunktion. Drei weitere Funktionen sind verbreitet: bcrypt, scrypt und Argon2id. Jede hat unterschiedliche Entwurfsziele und Sicherheitseigenschaften.

Bcrypt wurde 1999 entwickelt und verwendet einen auf Blowfish basierenden Schlüsselplan. Es ist resistent gegen GPU-Angriffe, weil es eine feste Speichermenge (4 KB) benötigt und einen eingebauten Kostenfaktor hat. Bcrypt ist weit verbreitet, hat aber eine maximale Passwortlänge von 72 Bytes. Es wird nicht für neue Systeme empfohlen, da es auf CPUs langsamer ist als Argon2id und keine variable Speichernutzung unterstützt.

Scrypt wurde 2009 entwickelt und ist speicherhärtend. Es benötigt eine große, konfigurierbare Speichermenge und CPU-Zeit. Scrypt ist resistent gegen ASIC- und GPU-Angriffe, da die Speicherbandbreite zum Engpass wird. Es wird in einigen Kryptowährungs-Wallets und Dateiverschlüsselungs-Tools eingesetzt. Allerdings ist scrypt weniger weit implementiert als PBKDF2 und hat keinen NIST-Standard.

Argon2id ist der Gewinner des Password Hashing Competition von 2015. Es ist die modernste und für neue Systeme empfohlene KDF. Argon2id ist speicherhärtend, CPU-härtend und resistent gegen Seitenkanalangriffe. Es gibt drei Varianten: Argon2d (datenabhängig), Argon2i (datenunabhängig) und Argon2id (hybrid). OWASP empfiehlt Argon2id für neue Anwendungen.

PBKDF2 bleibt die am weitesten verbreitete KDF, weil es einfach, standardisiert und in jeder großen Kryptobibliothek verfügbar ist. Es ist der Standard in iOS’ CommonCrypto, Android’s KeyStore und vielen Unternehmenssystemen. Für Anwendungen, die Argon2id aufgrund von Plattformbeschränkungen oder Kompatibilitätsanforderungen nicht nutzen können, ist PBKDF2 mit einer hohen Iterationszahl und Hardwarebindung eine starke Wahl.

Wie AppVault PBKDF2 verwendet

AppVault verwendet PBKDF2-HMAC-SHA256 mit 600.000 Iterationen und einem pro Installation eindeutigen 128-Bit-Salz. Das Salz wird während der Ersteinrichtung generiert und in der Secure Enclave des Geräts gespeichert. Der abgeleitete Schlüssel wird anschließend mit einem Schlüssel umschlossen, der innerhalb der Secure Enclave erzeugt wird und den Chip niemals verlässt. Das bietet hardwaregebundenen Schutz: Selbst wenn ein Angreifer die PBKDF2-Ausgabe extrahiert, kann er sie ohne den Secure-Enclave-Schlüssel nicht verwenden.

Die Mustersperre auf dem 5×5-Raster von AppVault wird in eine Passwortzeichenfolge umgewandelt. Diese Zeichenfolge wird zusammen mit dem Salz in PBKDF2 eingespeist. Der resultierende abgeleitete Schlüssel wird verwendet, um das Tresorverzeichnis und jede Datei einzeln mit AES-256-GCM und einer eindeutigen 96-Bit-Nonce pro Datei zu verschlüsseln.

Die Zero-Knowledge-Architektur von AppVault bedeutet, dass das Passwort das Gerät niemals verlässt. Die PBKDF2-Ableitung findet vollständig auf dem iPhone statt. AppVaults Server (die es nicht gibt) sehen weder das Passwort noch den abgeleiteten Schlüssel. Das Bedrohungsmodell geht davon aus, dass ein Angreifer physischen Zugriff auf das Gerät erlangen könnte – aber ohne das Passwort und den Secure-Enclave-Schlüssel bleibt der Tresor versiegelt.

Andere Tresor-Apps dieser Kategorie verfolgen unterschiedliche Ansätze bei der Schlüsselableitung. Die architektonischen Unterschiede – Iterationszahlen, Handhabung von Salzen, Hardwarebindung gegenüber reiner Software-Verwahrung – findest du auf den dedizierten Vergleichsseiten: AppVault vs. Vaultaire und AppVault vs. Keepsafe. AppVault veröffentlicht seinen gesamten Kryptografie-Stapel mit Primärquellen-Nachweisen – die Voraussetzung für jede unabhängige Überprüfung.

Praktische Überlegungen für Entwickler

Wenn du PBKDF2 implementierst, halte dich an diese Richtlinien:

• Verwende HMAC-SHA256 als PRF. SHA1 ist akzeptabel, erfordert aber mehr Iterationen.
• Generiere ein zufälliges Salz von mindestens 16 Bytes pro Benutzer oder Instanz.
• Setze die Iterationszahl auf die aktuelle OWASP-Empfehlung (600.000 für SHA-256, Stand 2026).
• Speichere Salz und Iterationszahl zusammen mit dem abgeleiteten Schlüssel (oder in den Tresor-Metadaten), damit die Ableitung wiederholt werden kann.
• Ziehe Hardwarebindung (z. B. Secure Enclave, TPM) in Betracht, um den abgeleiteten Schlüssel auch bei Kompromittierung des Geräts zu schützen.
• Verwende PBKDF2 nicht zur Passwortspeicherung in Authentifizierungssystemen, wenn Argon2id verfügbar ist. PBKDF2 eignet sich am besten für die Schlüsselableitung in lokalen Verschlüsselungsszenarien.

Fazit

PBKDF2 ist eine kampferprobte Schlüsselableitungsfunktion, die seit über zwei Jahrzehnten Passwörter und Verschlüsselungsschlüssel schützt. Es ist nicht die modernste KDF, aber die am weitesten unterstützte – und bei korrekter Konfiguration bietet sie starken Schutz vor Brute-Force-Angriffen. Die OWASP-Empfehlung von 600.000 Iterationen für SHA-256 ab 2026 stellt sicher, dass jeder Passwortversuch teuer genug ist, um Angreifer abzuschrecken.

AppVault verwendet PBKDF2 mit 600.000 Iterationen, einem pro Installation eindeutigen Salz und Secure-Enclave-Umschließung, um deine Dateien zu schützen. Die Kombination aus hoher Iterationszahl und Hardwarebindung macht den Tresor resistent gegen softwarebasierte und physische Angriffe. Keine Passwortzurücksetzung, kein Hintertürchen, keine serverseitige Schlüsselwiederherstellung. Die Sicherheit deiner Daten hängt von der Stärke deines Passworts und der Integrität der PBKDF2-Ableitung ab.

Für einen tieferen Einblick in die Implementierung der Kryptografie von AppVault sieh dir die Verschlüsselungsübersicht und das Bedrohungsmodell an.