Passwörter rich­tig spei­chern – Teil 3

Teil 3 der Serie zum Thema Passwörter richtig speichern beschäftigt sich mit der Vertiefung der der Sicherheit unserer Passworthashes.

Er baut direkt auf dem 2. Teil auf und setzt diesen voraus.

Hashes gesalzen und gepfeffert

Rainbow Tables sind ein großes Problem, wenn Passwörter nicht komplex genug sind. Hier kommen Salz (Salt) und Pfeffer (Pepper) ins Spiel.

Salt

Das Salt ist eine zufällige, individuelle Zeichenfolge je Passwort mit ausreichender Länge und Komplexität, welche einem Passwort angehängt wird. Passwort und individuelles Salt werden also kombiniert. Aus dieser Kombination wird dann der Hash-Wert errechnet.

Damit werden vorberechnete Rainbow Tables nutzlos und ein Angreifer muss einen eigenen Rainbow Table je Kennwort erstellen. Durch die Komplexität des Salts, vorausgesetzt er ist gut gewählt, kann die Erzeugung für den Angreifer schnell unwirtschaftlich werden.

Exkurs Kostenfaktor
Wirtschaftlichkeit bzw. der sog. Kostenfaktor ist ein zentrales wichtiges Kriterium, wenn wir von Attacken auf verschlüsselte Daten oder Hashes sprechen. Der Kostenfaktor beschreibt den theoretischen Invest, den ein Angreifer tätigen muss, um eine Verschlüsselung bzw. einen Hash zu brechen. Ist der Invest zu hoch (Zeit, Hardware, Strom, etc.), dann wird der Angriff unrentabel. Sicherlich gibt es Organisationen, bei denen Rentabilität nicht an vorderster Stelle steht, dennoch gilt für den gemeinen (Wirtschafts-) Cracker, dass ein monetäres Ziel mit dem Angriff verfolgt wird. Hier kann dann eine einfache Kostenrechnung aufgestellt werden.Faustregel: wir wollen das Cracken der Passwörter so teuer wie möglich machen.

Ein Salt sollte immer individuell für jeden Benutzer erzeugt werden. Damit muss der Angreifer für jedes Passwort eine eigene Rainbow Table erzeugen.

Wird nur ein einziges oder nur wenige Salts verwendet, wird die Sicherheit nicht signifikant erhöht. Der Angreifer muss nur herausfinden, an welcher Stelle das Kennwort gesalzen wird (am Anfang, am Ende,…) und kann durch Reduzierungsalgorithmen die Rainbow Table-Erzeugung extrem beschleunigen.

Selbiges gilt für schwache Salts wie es Microsoft bei Windows XP / Vista gemacht habt. Hier wurde der Benutzername als Salt verwendet – auch für Systemkonten wie „administrator“. Somit ist die Erzeugung eines Rainbow Tables trotz individuellem Salt dennoch wirtschaftlich, da der Algorithmus für die Salt-Erzeugung bekannt ist.

Ist der Salt für jedes Passwort individuell, so kann der Angreifer aus einem erfolgreichen Crack keine Rückschlüsse auf die übrigen Passwort Hashes ziehen.

Entsprechend muss er für jedes zu knackende Passwort nahezu komplett bei 0  von vorne anfangen.

Das Salt muss, genauso wie der Hash, irgendwo abgelegt und schnell zugreifbar sein. Da das individuelle Salt kein wirkliches Geheimnis ist, wird es meist zusammen mit dem Kennwort in einer eigenen Datenbank-Spalte bei den Benutzerdaten gespeichert.

Vor der Überprüfung des eigentlichen Kennwort Hashs wird zunächst das Salt aus der Datenbank geladen, dann das Passwort mit dem Salt gehashed und abschließend mit dem Ziel-Hash vergleichen.

Lange habe ich mich gefragt, warum das Salt kein „Geheimnis“ ist und einfach beim Hashwert in der Datenbank gespeichert werden kann, bis mir klar wurde:

Das Salt dient nicht dazu die Entropie des Kennworts zu erhöhen, sondern erschwert schlicht Rainbow Table-Attacken. Nicht mehr aber auch nicht weniger.

Ein Salt macht aus einem schwachen Passwort kein Starkes, sondern aus einem schwachen Hash zu einem schwachen Passwort einen starken Hash.

Pepper

Geht unsere Datenbank mit den Passwörtern verloren hat der Angreifer direkten Zugriff auf unsere Passwort-Hashes und auf die zughörigen Salts.

Auch wenn die Hürde zum Cracken der Passwörter selbst mit den ergaunerten Daten immer noch hoch ist, bleibt ein schwaches /unsicheres Passwort auch mit Hash + Salt noch ein schwaches Passwort.

Es gilt also hier die Komplexität des Kennworts zu erhöhen. Hier kommt das sog. Pepper ins Spiel. Als Pepper bezeichnet man eine Zeichenkette mit ausreichender Länge und Komplexität. Prinzipiell unterliegt ein guter Pepper-Wert den selben Kriterien wie ein guter Salt-Wert mit dem Unterschied, dass er nicht für jedes Passwort neu erzeugt und in der Datenbank abgelegt wird, sondern nur ein einziges mal erzeugt und dann sicher auf dem Server bzw. der Umgebung hinterlegt wird. Er darf nicht in der Datenbank gespeichert werden, denn wir wollen diesen Passwortzusatz unter allen Umständen vor dem Angreifer verbergen. Ergaunert er unsere Datenbank, dann kennt er unseren Pepper-Wert nicht. Diesen würde er nur durch direkten Zugriff auf unsere Umgebung ermitteln können.

Es gibt viele Varianten den Pepper in der Umgebung zu hinterlegen. Diese gehen von einer symmetrisch verschlüsselter Datei bis hin zu einer Kodierung direkt im Quellcode der Anwendung.

Wichtig ist hierbei eigentlich nur der Aspekt, dass der Pepper nicht zusammen mit unserem Salt in der Datenbank steht, sondern der Cracker eine weitere Hürde überwinden muss, um sich alle Informationen zu beschaffen, die benötigt werden, um die Hashes zu brechen.

Zusätzlich muss er sich erst mal im Klaren darüber sein, dass die Hashes nicht nur gesalzen, sondern auch gepfeffert sind.

Für die Härtung der Passwörter mit Pepper wird häufig die Verwendung eines sog. Key-Hash Message Authentication Code-Algorithmus (HMAC) empfohlen. Es ist aber genauso gängig den Pepper am Ende des eigentlichen Passworts anzufügen.

 

Vorteil
+ Passwort steht in keinem öffentlichen Rainbow Table
+ auch schwaches Passwort bekommt gehärteten Hash
+ individueller Hash auch bei Passwortgleichheit
+ erhöhte Entropie durch Salt & Pepper
+ Pepper ist weitere Hürde für den Angreifer
+ Implementierungen in den aktuellen Frameworks

Nachteil
– Salt muss zusätzlich in Datenbank gespeichert werden
– Pepper darf nicht verloren gehen
– Implementierungsaufwand höher
– Grafikkarten (GPUs) sind nach wie vor problematisch

Fazit
Durch die Verwendung von Salt und Pepper sind wir schon auf einem ziemlich guten Weg Hashes sicher abzulegen. Wir erschweren Brute-Force-Attacken, verhindern Rainbow Table-Attacken und stellen dem Angreifer mit dem Pepper eine weitere Hürde.

Im ersten Moment könnte man denken, dass hier die Reise zu ende ist und wir alles getan haben, um unsere Kennwörter maximal zu schützen und die Annahme ist gar nicht falsch. Allerdings haben wird noch nicht ein gravierendes Problem gelöst: Die GPUs der Grafikkarten werden immer schneller, können immer mehr Operationen parallelisieren und dank z.B. CUDA/OpenCL für jede Art der Rechenoperation nutzbar.

Entsprechend können bis 100Mio. Hashes pro Sekunde berechnet werden.

Das liegt vor allem auch daran, dass MD5 und die SHA-Familie extrem darauf ausgelegt sind, schnell und hardware-nah berechnet werden zu können. Dieser Segen ist für unseren Anwendungsfall allerdings eher ein Fluch.

 

Beispiel

Salt

Pepper

Download

Ein lauffähiges Beispiel kann in meinem Git-Repository abgerufen werden:
https://github.com/christianaschoff/Passworte-Teil3-SaltNPepper

tl;dr

Salt & Pepper sind ein guter Schritt in die richtige Richtung. Hier werden viele Angriffsvektoren verhindert. GPUs sind aber eine wachsende Gefahrenquelle.

Schnelleinstieg
Der Übersichtlichkeit halber ist der Artikel in mehrere Teile gegliedert:
Intro: Vorwort
Teil 1: Klartext
Teil 2: MD5 und SHA
Teil 3: Salt & Pepper
Teil 4: BCrypt
Teil 5: BCrypt & Pepper und Gesamt-Fazit

Christian Aschoff

Christian Aschoff

Senior IT-Berater bei BROCKHAUS AG
Christian Aschoff ist bei der BROCKHAUS AG in der Individualentwicklung mit Microsoft-Technologien tätig. Darüber hinaus beschäftigt er sich mit übergreifenden Themen wie IT-Security, iOS-Entwicklung mit Mono und Unity 3D. Als jemand, dem Sicherheit am Herzen liegt, schreibt er für das blogHAUS hauptsächlich über Themen aus dem Bereich Security.
Christian Aschoff
<< Vorheriger Beitrag
Nächster Beitrag >>

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.