Passwörter speichern: Warum hasht man sie, statt sie zu verschlüsseln – und wozu dann noch ein „Salt“?

Der Unterschied ist tatsächlich der Kern der Aufgabe, deshalb einmal sauber:

Verschlüsselung ist umkehrbar. Mit dem passenden Schlüssel wird aus dem Geheimtext wieder der Klartext. Das ist gewollt, wenn man die Daten später wieder lesen muss (E-Mail, Datei, Datenübertragung). Für Passwörter ist genau das das Problem: Der Schlüssel muss irgendwo liegen, meist auf demselben System. Wird der Server kompromittiert, hat der Angreifer im schlimmsten Fall Datenbank und Schlüssel – und damit alle Passwörter im Klartext.

Eine kryptografische Hashfunktion ist eine Einwegfunktion. Eigenschaften, die du in der Klausur nennen kannst:

• nicht (praktisch) umkehrbar – aus dem Hash lässt sich das Passwort nicht zurückrechnen
• deterministisch – gleiche Eingabe ergibt immer denselben Hash
• feste Ausgabelänge, egal wie lang die Eingabe ist
• Lawineneffekt – ein geändertes Zeichen ergibt einen völlig anderen Hash
• kollisionsresistent – zwei verschiedene Eingaben mit gleichem Hash zu finden, ist praktisch unmöglich

Wie funktioniert dann der Login? Das System muss das Passwort gar nicht kennen. Es hasht die Eingabe beim Login und vergleicht die Hashes. Stimmen sie überein, war das Passwort richtig. Deshalb schicken seriöse Dienste bei „Passwort vergessen“ auch einen Reset-Link und nicht dein altes Passwort – sie kennen es schlicht nicht.

Und das Salt? Deine Überlegung ist genau richtig: Ohne Salt hat „Sommer2026!“ bei jedem Nutzer denselben Hash. Ein Angreifer kann dann vorberechnete Tabellen (Rainbow Tables) nutzen und sieht außerdem sofort, welche Nutzer dasselbe Passwort haben.

Ein Salt ist ein zufälliger Wert pro Nutzer, der vor dem Hashen an das Passwort gehängt wird. Er steht tatsächlich im Klartext neben dem Hash – das ist kein Fehler, denn er muss nicht geheim sein. Seine Aufgabe ist nur, jeden Hash einzigartig zu machen:

• gleiche Passwörter → unterschiedliche Hashes
• vorberechnete Tabellen sind wertlos, weil sie für jedes Salt neu berechnet werden müssten
• der Angreifer muss jeden Nutzer einzeln angreifen statt alle auf einmal

Manche Systeme nutzen zusätzlich einen Pepper: einen geheimen Wert, der außerhalb der Datenbank liegt. Das ist aber ein Zusatz, nicht der Standardteil der Klausurantwort.

Daniel hat die Klausurantwort komplett, ich ergänze den Punkt, bei dem viele Skripte (und leider auch manche echte Software) stehen bleiben: SHA-256 allein ist für Passwörter trotzdem keine gute Wahl.

Der Grund: SHA-256 ist darauf optimiert, schnell zu sein – super für Prüfsummen und Signaturen, schlecht für Passwörter. Wer eine gestohlene Datenbank hat, probiert einfach Wörterbücher und Varianten durch, und auf einer einzigen Grafikkarte sind das Milliarden Versuche pro Sekunde. Das Salt verhindert zwar vorberechnete Tabellen, aber nicht das gezielte Durchprobieren eines einzelnen Kontos.

Deshalb nutzt man für Passwörter absichtlich langsame Verfahren:

• bcrypt – mit einstellbarem Kostenfaktor
• PBKDF2 – viele tausend Iterationen einer Hashfunktion
• scrypt und Argon2 – zusätzlich speicherintensiv, was massenhaftes Parallelrechnen auf Grafikkarten teuer macht. Argon2 hat 2015 die Password Hashing Competition gewonnen und gilt heute als Empfehlung.

Für den Nutzer fällt eine Viertelsekunde beim Login nicht auf. Für einen Angreifer, der Milliarden Kandidaten testen will, ist das der Unterschied zwischen Stunden und Jahrhunderten. Alte Verfahren wie MD5 oder SHA-1 gelten für diesen Zweck als unsicher.

Mein Merksatz für die Klausur:

Verschlüsselung schützt Daten, die man wieder lesen muss. Hashing schützt Daten, die man nur prüfen muss.

Und als Grenze, falls „beurteilen“ gefragt ist: Kein Hashverfahren rettet ein schwaches Passwort wie „123456“ – das steht in jedem Wörterbuch ganz oben. Deshalb gehören Passwortrichtlinien und Zwei-Faktor-Authentifizierung in eine vollständige Antwort zur Zugangssicherheit dazu. Einordnung in die Schutzziele: Hashing unterstützt vor allem Integrität und schützt bei Passwörtern indirekt die Vertraulichkeit der Konten.