Teil 3 – Fehler bei der Speicherung sensibler Daten

Sep. 12, 2025

—

von

in Cryptographic Failures, Cyber Security, Websecurity

Wenn Daten im Schrank statt im Tresor landen

Verschlüsselung ist wie ein Tresor: Sie schützt Daten, selbst wenn jemand in den Raum eindringt. Leider werden viele sensible Informationen nicht im Tresor abgelegt, sondern einfach im Schrank – leicht zugänglich für jeden, der vorbeikommt. Genau das passiert, wenn Anwendungen Daten im Klartext oder mit schwacher Kryptografie speichern.

Klartext-Passwörter – der Klassiker

Noch immer speichern manche Anwendungen Passwörter direkt in der Datenbank:

id | username | password
1  | alice    | secret123
2  | bob      | qwerty

Wenn ein Angreifer Zugriff auf die Datenbank bekommt, hat er sofort die vollständige Liste aller Passwörter – oft wiederverwendet für E-Mail oder Banking.
Reale Vorfälle wie der RockYou-Dump (2009) oder der Facebook-Klartext-Skandal (2019) zeigen, dass dieses Problem bis heute existiert.

Unsichere Hashes

Manche Systeme „schützen“ Passwörter, aber mit veralteten Algorithmen wie MD5 oder SHA-1.
Problem: Diese Hashes lassen sich mit moderner Hardware und Rainbow Tables in Sekunden knacken.

Beispiel:

id | username | password_hash
1  | alice    | 5ebe2294ecd0e0f08eab7690d2a6ee69  (MD5 für "secret")

Ein Angreifer muss nur die Hashliste mit bekannten Werten vergleichen – schon ist das Passwort offengelegt.

Fehlende Salts

Auch wenn ein starker Hash genutzt wird, fehlt oft ein Salt – ein zufälliger Wert, der jedem Passwort hinzugefügt wird.
Ohne Salt gilt: Zwei gleiche Passwörter erzeugen denselben Hash. Angreifer erkennen sofort, welche Nutzer dasselbe Passwort teilen.

Fehlerhafte Verschlüsselung

Nicht nur Passwörter, auch Kreditkarten- oder Gesundheitsdaten sind oft betroffen. Häufige Fehler:

Wiederverwendung desselben IV (Initialization Vector): macht Muster in Daten sichtbar.
Eigene Verschlüsselungsalgorithmen: Entwickler „erfinden“ Kryptografie, die leicht zu brechen ist.
Keys im Code gespeichert: const encryptionKey = "supersecretkey123"; Jeder mit Zugriff auf den Code oder das Repository kennt den Schlüssel.

Geheimnisse im Log oder Repo

Ein weiteres Problem: sensible Daten landen in Logs oder Git-Repositories.

Passwort-Resets im Log: „User Alice new password: secret123“.
API-Keys versehentlich auf GitHub hochgeladen.
Angreifer durchsuchen gezielt öffentliche Repos nach solchen Leaks.

Best Practices für sichere Speicherung

Passwörter

Immer mit starken Hashverfahren speichern: bcrypt, scrypt oder Argon2.
Immer mit Salt und einem Work-Factor (z. B. bcrypt cost = 12).
Keine Wiederverwendung von Passwörtern zwischen Systemen.

Datenverschlüsselung

Symmetrische Verfahren wie AES-256 nutzen.
Einzigartige IVs pro Verschlüsselungsvorgang.
Keys niemals im Code – stattdessen Key-Stores oder Secrets Manager (z. B. HashiCorp Vault, AWS KMS).

Minimierung

Nur speichern, was wirklich nötig ist.
Sensible Daten so kurz wie möglich aufbewahren (z. B. Kreditkarten nur bis zur Transaktion).