Pepper (Cryptography)

In der Config (.env): PEPPER_SECRET="SuperGeheimUndLang"

Im Code:

full_input = password + salt + os.getenv("PEPPER_SECRET")
db_hash = bcrypt.hash(full_input)

Wichtig: Wenn du den Pepper verlierst, kann sich niemand mehr einloggen. Alle Passwörter sind unbrauchbar. Backups sind lebenswichtig!

1. Pepper Rotation

Was, wenn man den Pepper ändern muss? Schwer. Man müsste alle Hashes neu berechnen. Aber man kennt die Passwörter nicht. Lösung: Versionierte Peppers. Man speichert beim Hash eine ID: v1:$2b$.... Der Code hat eine Liste: v1 = "SecretA", v2 = "SecretB". Beim Login prüft man: Ist es v1? Nutze SecretA. Beim nächsten erfolgreichen Login hashed man das Passwort neu mit v2 und speichert das Update. (Rolling Update).

2. HSM (Hardware Security Module)

Der "Profi-Pepper". Statt den Pepper im Code zu haben (den der Admin lesen kann), schickt man den Hash an ein externes Gerät (HSM). Das HSM macht den finalen HMAC. Der Key verlässt niemals das HSM. Selbst wenn der Hacker Root auf dem Server hat, kommt er nicht an den Key im HSM.

3. HMAC als Pepper

Statt hash(pw + pepper) nutzt man oft HMAC(pw, pepper). HMAC ist kryptografisch robuster gegen bestimmte Angriffe (Length Extension) als einfaches Aneinanderhängen (Concatenation).

1. Key Derivation Function (KDF) Concatenation Bug

Eine triviale, aber fatale Methode Peppers zu implementieren ist die String-Konkatenation via simpler Hash-Funktionen, wie z.B. $MD5(password + pepper)$. Moderne Cracker nutzen "Length Extension Attacks" bei $Merkle-Damgård$ Konstruktionen. Wenn ein Angreifer $hash(m_1)$ kennt, kann er kryptografisch valides $hash(m_1 + m_2)$ berechnen, ohne den originalen $m_1$ Content zu kennen. Deshalb ist die korrekte Integration eines Peppers zwingend in Form des asymmetrischen $HMAC(Key=Pepper, Message=Password)$ zu bauen. Noch besser: Man injiziert den Pepper als Key in etablierte Slow-Hashes (z. B. Argon2id), die von Natur aus Memory-Hard Constraints besitzen (sie blockieren dediziert den Bau von parallelen ASIC/GPU Hash-Cracking Clustern durch massiven RAM Bedarf pro Berechnungs-Thread).

2. Envelope Encryption & HSM Lifecycle

In Enterprise-Sicherheitsarchitekturen (wie AWS KMS oder HashiCorp Vault) existiert der Pepper niemals als purer String im Arbeitsspeicher der Applikation. Man appliziert "Envelope Encryption": Der User reicht sein Passwort ein. Die App sendet das $Salted-Hash$ asynchron über TSL an ein dediziertes Hardware Security Module (HSM). Das HSM verknüpft dieses intern mit dem in die Hardware gebrannten Pepper (Data Encryption Key) und liefert das $Final-Hash$ zurück. Falls die App-Server vollständig kompromittiert sind (Root-Access via RCE-Exploit), kann der Angreifer den Pepper nicht per RAM-Scraping auslesen. Er kann höchstens das HSM API anspringen (Oracle-Angriff) und Rate-Limits über sich ergehen lassen. Verhindert man das rechtzeitig, bleibt der Cryptographic Boundary des HSM unbeschadet intakt.

3. Blind SQL Injection & Temporal Attack Vectors

Der Schutz durch den Pepper erlischt paradoxerweise, wenn die Applikation gegen Blind SQL Injection oder Timing Side-Channel anfällig ist. Bei einem schlecht gebauten Login-Controller ($If \ hash == db_hash$) verwendet der Code oft eine einfache string-vergleichende Methode (==). Diese bricht den CPU-Abgleich beim ersten inkorrekten Buchstaben ab (Kurzschlussverfahren). Ein fortgeschrittener Hacker mit Zugang zum Login-Endpoint kann durch zehntausende Requests im Mikrosekundenbereich die Time-Latenzen analysieren, und so den internen Hash Byte für Byte rekonstruieren oder sogar das Plaintext Pass Hash Matching erahnen, ganz unabhängig davon, dass ein "Pepper" aktiv ist. Gegenmaßnahme: Konstante Zeitvergleiche via crypto.timingSafeEqual() in Node.js oder konstante DB-Abfragen.