Das Salz in der Suppe: Salts als unverzichtbare Zutat bei der Passwortspeicherung für Applikationen

Ein Secutorial von IT Security Consultant Julian Gruber-Roët

Fast schon wöchentlich tauchen geknackte Passwortdatenbanken von Webanwendungen in Hackerforen, Darknet-Handelsplattformen oder öffentlichen Pastebins auf. Darunter sind Anwendungen mit einigen Tausend Benutzern, aber auch solche von 'Global Playern' mit hundert Millionen Benutzeraccounts.

Gleichzeitig bieten immer mehr Unternehmen den Dienst an, geknackte Datenbanken zu durchsuchen und ihre Kunden zu warnen, wenn deren Passwörter darin vorkommen. Viele Online-Passwortmanager, Internetbrowser wie Google Chrome oder Antivirensoftware bieten mittlerweile diese Möglichkeit. Unter den ersten war allerdings sicherlich der Sicherheitsforscher Troy Hunt mit seinem Projekt "haveibeenpwned", bei dem jeder selbst die veröffentlichten Datenbanken nach den eigenen E-Mail-Adressen, Telefonnummern und Passwörtern durchsuchen kann.

Als Benutzer hat man es nicht in der Hand, welche Firmen ihre Passwortdatenbanken durch technische oder menschliche Schwachstellen an Hacker verlieren, und so bleibt – wie so oft – nur die Empfehlung von starken Passwörtern und, wenn möglich, die Verwendung einer Multi-Faktor-Authentifizierung, um die Auswirkungen eines Passwortdiebstahls abzumildern.

Aber tatsächlich ist die sichere Speicherung der Passwörter in der Datenbank ein mindestens genauso wichtiges Thema wie die Komplexität des eigentlichen Passworts. Und dabei geht es nicht um die generelle Sicherheit einer Firma oder Organisation, die Hacker von ihrer Datenbank fernhalten soll. Sondern es geht darum, was passiert, wenn es eigentlich schon zu spät ist und Hacker die komplette Datenbank bereits in ihren Besitz bringen konnten. Die "Last Line of Defense" steht also in Rede.

Glücklicherweise hat es sich schon vor längerer Zeit durchgesetzt, Passwörter niemals im Klartext abzuspeichern, sondern sie vorher kryptografisch zu schützen. Und dieser Standard wird mittlerweile auch von der überwiegenden Mehrzahl der Entwickler umgesetzt. Durch diesen Schutz werden Angreifer gezwungen, die Passwörter durch einen Rateangriff auszuprobieren.

Passwort-Rateangriffe und Cracking

Bei einem Online-Rateangriff geben Angreifer automatisiert Passwortversuche in ein normales Loginformular ein. Diese Versuche werden dann von der Gegenseite – also beispielsweise von einem Webserver – entgegengenommen und mit der Benutzerdatenbank verglichen. Dies bietet den Betreibern der Webseite einen optimalen Weg zur Verteidigung gegen Rateangriffe: Der Webserver kann einfach nach einigen falschen Passwortkandidaten aufhören, weitere Versuche zu bearbeiten oder jeden weiteren Versuch zu verzögern. Dasselbe gilt auch für andere Passworteingaben wie die PIN am Handy oder der Bankcard. In diesen Fällen ist nur eine sehr geringe Anzahl von Rateversuchen möglich und somit selbst eine vierstellige PIN nahezu unknackbar.

Sobald Angreifer im Besitz der Datenbank sind, sieht es allerdings anders aus. In diesem Fall gibt es keine Gegenseite mehr, die Versuche blockieren oder verzögern kann. Je nach Rechenleistung können Angreifer mehrere hundert Millionen Passwörter pro Sekunde raten. Die Komplexität der Passwörter bestimmt dabei, wie viele Rateversuche nötig sind, während der verwendete Kryptoalgorithmus bestimmt, wie schnell die Rateversuche durchgeführt werden können.

Vor diesem Hintergrund stellt sich nun die Frage, wie Passwörter in einer Datenbank sicher abgespeichert werden sollen.

Verschlüsselung

Passwörter können mit einem symmetrischen Schlüssel verschlüsselt werden. Dieses Verfahren bietet eine erhöhte Sicherheit gegenüber Klartextpasswörtern. Es bringt allerdings auch einige signifikante Nachteile mit sich, weshalb die symmetrische Verschlüsselung als alleiniger Schutz nicht ausreicht. Zum einen müssen Applikationen, die die Datenbank zur Benutzerverwaltung verwenden, Zugriff auf den verwendeten Schlüssel haben, um die eingegebenen Passwörter damit zu verschlüsseln. Dies bedeutet, dass Angriffe über Remote Code Execution (RCE)-Schwachstellen in diesen Applikationen auch Zugriff auf den Schlüssel haben und somit die Verschlüsselung aufgebrochen werden kann. Zum anderen besteht der größte Nachteil darin, dass alle Passwörter mit demselben Schlüssel verschlüsselt werden, also nur ein einziger Schlüssel erraten werden muss, um alle Passwörter zu knacken. Außerdem kann eine Mehrfachverwendung von Passwörtern direkt aus der verschlüsselten Form abgelesen werden.

Rein konzeptionell ist eine Verschlüsselung ein umkehrbares Verfahren. Für die sichere Speicherung von Passwörtern ist allerdings die Entschlüsselung kein relevanter Anwendungsfall, da alle Passwortprüfungen immer in der verschlüsselten Form durchgeführt werden können. 

Anstelle einer Verschlüsselung sollte eine unumkehrbare kryptografische Funktion verwendet werden, sogenanntes Hashing.

Hashing

Hashing ist eine unumkehrbare kryptografische Funktion, bei der eine Eingabe in eine pseudozufällige Ausgabe mit einer festen Länge überführt wird. Neben der Passwortspeicherung wird Hashing verwendet, um Prüfsummen von Dateien oder Netzwerkpaketen zu erstellen. Einmal gehashte Passwörter können somit nicht mehr in ihre Klartextform überführt werden, außer durch Cracking, also einen Rateangriff. Aufgrund der festen Ausgabelänge besteht auch kein Grund mehr, die maximale Länge eines Passworts zu beschränken, selbst wenn in der Datenbank nur begrenzter Platz zur Verfügung steht.

Der Hashing-Algorithmus sollte dabei so gewählt werden, dass er gezielt zeit- und ressourcenintensiv ist. Dadurch kann ein Offline-Rateangriff signifikant erschwert werden. Für einen Endnutzer geht eine Verzögerung von einer Sekunde durch das Hashing des Passworts während des Loginversuchs in den normalen Ladezeiten einer Anwendung unter, während für einen Angreifer eine Sekunde bei vielen Millionen Rateversuchen direkt zu einem Zeitaufwand mit prohibitiver Wirkung wird.

Entsprechend sollten effiziente Algorithmen wie die SHA-Familie oder MD5 nicht verwendet werden. Stattdessen sollte eine der Hash-Funktionen, die gezielt zur Speicherung von Passwörtern entwickelt worden und bewusst rechenintensiv sind, verwendet werden. Aktuell zählen zu den empfohlenen Verfahren Mitglieder der Argon-Familie, speziell Argon2id oder die Algorithmen yescrypt, scrypt, bcrypt oder PBKDF2. 
Neben dem beschriebenen Ressourcenaufwand beim Hashing bieten diese Algorithmen auch einen weiteren Vorteil, nämlich die standardmäßige Verwendung eines Salt.

Salt and Pepper

Neben dem eigentlichen Hash-Verfahren gibt es noch weitere Sicherheitsmechanismen, die genutzt werden können, um die Sicherheit der Passwörter weiter zu erhöhen.
Auch bei Hashing produzieren gleiche Passwörter den gleichen Hash. Spezialisierte Angreifer können also noch bevor sie je eine Passwortdatenbank in ihrem Besitz bringen, die Hashes für häufige Passwörter berechnen oder sogenannte "Rainbow Tables" erstellen, die das anschließende Hash-Cracking beschleunigen. Durch die Zugabe eines zufällig, für jedes Passwort einzigartig generierten Wertes, eines Salt, der zusammen mit dem Passwort gehasht und gespeichert wird, können diese Vorberechnungen verhindert werden. Durch das Salt ergeben auch identische Passwörter verschiedene Hashes und müssen einzeln gecrackt werden. Entsprechend gilt die Verwendung von Salted Hashes mittlerweile als Industriestandard und wird von den vorher genannten Algorithmen standardmäßig verwendet.

Eine Verschlüsselung der Passwörter alleine hat viele Nachteile. Ein großer Nachteil des Hashing kann aber behoben werden durch die Verwendung eines geheimen Schlüssels – Pepper oder Secret Salt genannt –, der wie bei der Verschlüsselung außerhalb der Datenbank gespeichert wird und in den Hashing-Prozess mit einfließt. So kann zusätzliche Sicherheit geschaffen werden. Auch bei perfekten Hash-Algorithmen kann ein einfaches Passwort in wenigen Versuchen erraten werden. Wird zusätzlich ein Pepper verwendet, so benötigen auch schwache Passwörter eine sehr hohe Anzahl von Rateversuchen, da gleichzeitig der Pepper geknackt werden muss. Das Speichern des Schlüssels auf einem anderen System oder zumindest einer anderen Applikation soll dabei verhindern, dass Angreifer diesen gemeinsam mit der Datenbank kompromittieren können.

  Länge  Speicherung Schutz gegen
Salt kurz Klartext mit dem Passwort in der Datenbank Vorberechnung, identische Passwörter
Pepper    lang Quellcode der Applikation oder Konfigurationsdateien    schwache Passwörter

 

TL;DR oder: Das Ganze in Kürze

  • Passwörter müssen durch kryptografische Funktionen geschützt werden.
  • Hashing der Passwörter bietet einen besseren Schutz als Verschlüsselung.
  • Ein ressourcenintensiver Hashing-Algorithmus bietet Schutz vor Cracking-Angriffen, indem er die Rateversuche verlangsamt und Parallelisierung entgegenwirkt.
  • Die Verwendung eines Salt während des Hashings verhindert die Vorberechnung der Hashes und die Erstellung von Rainbow Tables. Daher sollte immer ein Salt genutzt werden.
  • Als zusätzliches Geheimnis kann ein Pepper verwendet werden, um schwache Passwörter zusätzlich abzusichern.

Die folgenden praktischen Empfehlungen sind der Cheat Sheet Series des Open Web Application Security Projects (OWASP) in absteigender Stärke entnommen und bilden ein gutes Verhältnis zwischen Sicherheit und Ressourcenaufwand für die Applikation ab:

  1. Argon2id mit 15 MiB Arbeitsspeicher, 2 Iterationen und einfacherer Parallelisierung
  2. scrypt mit mindestens einem Kostenparameter von 216, Blockgröße von 1024 Bytes und einfacher Parallelisierung
  3. PBKDF2 mit Arbeitsfaktor 310,000 und Hash-Funktion HMAC-SHA-256

Werden bei der Speicherung von Passwörtern für Applikationen all diese Empfehlungen berücksichtigt, ist das derzeit höchstmögliche Maß an Sicherheit gewährleistet.

Ihr direkter Kontakt zu SySS +49 (0)7071 - 40 78 56-0 oder anfrage@syss.de | IN DRINGENDEN FÄLLEN AUSSERHALB DER GESCHÄFTSZEITEN +49 (0)7071 - 40 78 56-99

Als Rahmenvertragskunde wählen Sie bitte die bereitgestellte Rufbereitschaftsnummer

Ihr direkter Kontakt zu SySS +49 (0)7071 - 40 78 56-0 oder anfrage@syss.de

IN DRINGENDEN FÄLLEN AUSSERHALB DER GESCHÄFTSZEITEN +49 (0)7071 - 40 78 56-99

Als Rahmenvertragskunde wählen Sie bitte die bereitgestellte Rufbereitschaftsnummer

Direkter Kontakt

+49 (0)7071 - 40 78 56-0 oder anfrage@syss.de

IN DRINGENDEN FÄLLEN AUSSERHALB DER GESCHÄFTSZEITEN

+49 (0)7071 - 40 78 56-99

Als Rahmenvertragskunde wählen Sie bitte die bereitgestellte Rufbereitschaftsnummer