Background · 7 KI, Daten & neue Risiken

Kryptografisches Hashing — Referenz.

Praxisnahe Hashing-Referenz: wann Kollisionsresistenz zählt, wann Length-Extension schadet, und was heute zu wählen ist.

Use-Case → Auswahl

Passwort-Storage. Argon2id (bevorzugt), bcrypt (akzeptabel), scrypt (akzeptabel). Niemals SHA-256/SHA-512 direkt, niemals MD5. OWASP-empfohlene Argon2id-Params (2024): t=2, m=19 MiB, p=1 für interaktiv; t=3, m=64 MiB, p=4 für höhere Stakes. Tunen bis ein Hash ~100 ms auf deiner Hardware dauert.
Generisches Content-Addressing. SHA-256. Schnell genug, allgegenwärtige Lib-Unterstützung, kein praktischer Break. BLAKE3 wenn Performance mehr zählt als Ökosystem.
File-Equality / Dedup wo Angreifer keine Files liefern kann. BLAKE3 oder xxHash. Massiver Durchsatz; Kollisionsresistenz nicht erforderlich.
Authentifizierte Message-Integrität. HMAC-SHA-256 wenn Hash sein muss. Besser: AEAD (AES-GCM, ChaCha20-Poly1305), gibt Encryption + Integrität zusammen. MAC nicht durch Konkatenation von Key und Message handrollen.
Digitale Signaturen. SHA-256 mit RSA-PSS oder ECDSA P-256 oder Ed25519. SHA-1, MD5 vermeiden (nicht mehr kollisionsresistent — Chosen-Prefix-Kollisionen demonstriert).
Key-Derivation aus Low-Entropy-Input. HKDF (Extract + Expand) mit SHA-256. Nicht bcrypt/Argon2 (die sind für Passwort-Verifikation, nicht Key-Derivation).
Commitment-Schemes / Merkle-Trees. SHA-256 (Bitcoin) oder BLAKE3 / Poseidon (zk-friendly).
Random-ID-Generierung. Nicht hashen, einfach CSPRNG-Bytes base32-kodiert. 16 Bytes = 128 Bit = sicher.

Length-Extension-Angriff

Was es ist. Gegeben H(key || message) und Länge von key, berechnet Angreifer H(key || message || padding || extra) ohne key zu kennen.
Vulnerable. SHA-1, SHA-256, SHA-512 (jede Merkle-Damgård-Konstruktion).
Nicht vulnerable. SHA-3 (Keccak-Sponge), BLAKE2, BLAKE3, HMAC über beliebigen Hash.
Fix. HMAC nutzen: HMAC(key, message). Library macht es korrekt. Oder AEAD nutzen.

Häufige Fehler

MD5 für "Non-Security"-Uses. Dann nutzt jemand das Ergebnis als Cache-Key, dann als ETag, dann als Security-Boundary. BLAKE3 oder SHA-256 stattdessen — gleiche Bequemlichkeit, kein Future-Foot-Gun.
SHA-256 für Passwort-Storage. GPU-Cracking: 10 GH/s. Argon2id: ~10 H/s/GB. 9 Größenordnungen Unterschied.
Hash kürzen, um "Platz zu sparen". 64-Bit-truncated SHA-256 hat 32-Bit-Kollisionsresistenz via Birthday-Bound — praktisch angreifbar.
Salt-Reuse / kein Salt. Wiederverwendetes Salt = Rainbow-Table-Angriff. Pro-User-Random-Salt immer.
Vergleich via == auf Hashes für Auth. Timing-Leak. Constant-Time-Compare nutzen (crypto.timingSafeEqual, hmac.compare_digest).
Custom-MAC-Konstruktion. "H(key || msg)" — Length-Extension. "H(msg || key)" — Kollision auf H erlaubt Forgery. Einfach HMAC nutzen.

Migrationspfade

MD5-Passwort-Hashes →. Beim nächsten Login mit Argon2id rehashen und speichern. Alter MD5-Hash nach Grace-Window löschbar, in dem User sich eingeloggt haben.
SHA-1-Signaturen →. Mit SHA-256 neu signieren. Beide während Transition verifizieren; SHA-1 nach Cut-Off ablehnen.
HMAC-SHA-1 (z.B. Legacy AWS Sig v2) →. HMAC-SHA-256 (Sig v4).
bcrypt nähert sich Cost-Factor-Ceiling →. Argon2id. Beim User-Login wrappen.

FaustregelFür 99% der Use-Cases ist der Entscheidungsbaum: Passwörter → Argon2id; Integrität mit Key → HMAC-SHA-256 oder AEAD; Integrität ohne Key → SHA-256 oder BLAKE3; Random-IDs → CSPRNG, kein Hash. Fast alles andere ist ein Custom-Fehler.