Grundlagen: Sicheres Passwort Hashing mit Salts

Wer Software entwickelt und dies im Web-Umfeld tut, der hat sicherlich schon das ein oder andere Login-System geschrieben oder zumindest Berührungspunkte in diesem Bereich gehabt. Neben der Logik eines sicheren Login- bzw. User-Systems an und für sich, ist das sichere Speichern von Passwörtern einer der wichtigsten Punkte während der Implementierung.

Selbst wenn der eigentliche Code des Logins zu 100 Prozent fehlerfrei und sicher ist (wovon man in der Praxis nie ausgehen sollte), so kann es durch Sicherheitslücken in der Serversoftware immer noch zu Einbrüchen bzw. Hacks kommen. Es gibt immer eine Variable, auf die man keinen Einfluss hat und so werden tagtäglich Webseiten gehackt, kompromittiert und komplette Datenbanken mit Usernamen und Passwörtern ausgelesen.

Um die Nutzer im Falle eines solchen Hacks bestmöglich zu schützen, sollten die Passwörter durch Salts (=Salz; eine Methodik aus der Kryptologie) geschützt werden.

In der Praxis sieht es jedoch leider so aus, dass vielen Entwicklern zwar bewusst ist, dass sie Passwörter salten sollten, die Meinungen und Ansätze über das “Wie”, also die Umsetzung, jedoch stark voneinander abweichen und teilweise so falsch sind, dass sich der gut gemeinte “Schutz” eher ins Negative auswirkt.

Bestseller Nr. 1

Sichere Webanwendungen: Das Praxisbuch

5,18 EUR

Bei Amazon kaufen Preis inkl. MwSt., zzgl. Versandkosten

Bestseller Nr. 2

Sichere Webanwendungen mit PHP

32,50 EUR

Bei Amazon kaufen Preis inkl. MwSt., zzgl. Versandkosten

Bestseller Nr. 3

Sichere Webanwendungen

0,59 EUR

Bei Amazon kaufen Preis inkl. MwSt., zzgl. Versandkosten

Deshalb möchte ich nachfolgend einmal mit dem Thema Passwort Hashing und Salting aufräumen und vom “Was ist eigentlich Passwort Hashing” bis hin zu “Best Practices für Passwort Hashing” die gesamte Themenpalette abarbeiten.

Was ist Passwort Hashing?

Passwort Hashing bedeutet das Anwenden einer Hashfunktion auf ein Passwort. Eine Hashfunktion (“hash'” ist englisch und steht für zerhacken) ist eine sogenannte Streuwertfunktion, die es ermöglichst große Eingabemengen auf (meist kleinere) Zielmengen zu projizieren. Oftmals haben die Zielmengen auch festgelegte Länge.

Für den Secure Hash Algorithm (kurz SHA) beträgt die Länge der Zielmenge z.B. immer 160 Bit, die wiederum oftmals als 40-stellige Hexadezimalzahl notiert wird.

Hat man also das Passwort “Geheim” und wendet darauf SHA1 an, so ergibt sich folgende Ausgabe:

sha1('Secret') == f4e7a8740db0b7a0bfd8e63077261475f61fc2a6

Lautet das Passwort hingegen “SuperLangesUndSehrSehrGeheimesPasswortMitVielenZahlen6489451456498489494894894” ergibt sich folgender Hash (unter Anwendung von SHA):

sha1('SuperLongAndVerySecretPasswordWithManyNumbers6489451456498489494894894') == 08e114b6377129fa37fed8f86af2e06bf62fad71

Trotz der viel längeren Eingabe hat die Zielmenge immer noch dieselbe Länge von 40 Zeichen. Hieraus ergibt sich ein Problem von Hashfunktionen. Da die Eingabemenge größer sein kann als die Zielmenge, kann es vorkommen, dass zwei unterschiedliche Eingaben den gleichen Hashwert erzeugen. Dies nennt man eine Kollisionen.

Wenn statt dem Passwort der Hash in der Datenbank gespeichert werden soll, so sind Kollisionen ein nicht erwünschter Seiteneffekt. Zudem ist nicht jede Hashfunktion zur Anwendung auf Passwörter geeignet. Aus diesem Grund gibt es eine Unterart der Hashfunktionen, die sogenannten kryptologischen Hashfunktionen.

Dieser Typus von Hashfunktionen zeichnet sich durch eine Reihe von Merkmalen aus. So ist eine kryptologische Hashfunktion per Definition kollisionsresistent, wobei eine Kollisionen theoretisch immer noch möglich ist, jedoch mit einem unüberwindbar hohen Aufwand verbunden ist, sodass praktisch keine Kollision gefunden werden kann. Weiter sollen schon kleinste Änderungen an der Eingabemenge eine scheinbar willkürliche Änderung der Zielmenge bewirken. Zudem soll es nicht möglich sein, aus einem Hash einer kryptografischen Hashfunktion die Eingabe zu rekonstruieren.

Wenn für kryptologische Hashfunktionen dennoch Kollisionen gefunden werden, dann ist entweder eine Schwachstelle im Algorithmus entdeckt worden oder der Aufwand zum Finden einer Kollision ist im Verhältnis zum technischen Fortschritt nicht mehr groß genug um eine Kollisionsresistenz zu sichern. In diesem Falle spricht man davon, dass der jeweilige Algorithmus “broken” (=zerbrochen, kaputt) ist. Von der Nutzung solcher Algorithmen sollte abgesehen werden. (Dies gilt z.B. auch für die MD5-Funktion.)

Zum Passwort-Hashing sollten also ausschließlich kryptologische Hashfunktionen verwendet werden.

Der Standardablauf zur Verwaltung von Nutzerdaten und Passwörten unter Verwendung von Hashfunktionen sieht wie folgt aus:

1. Der Nutzer registriert sich mit Nutzernamen und Passwort.
2. Das Passwort wird vorm Speichern in der Datenbank gehasht und nur der Hash wird in der Datenbank abgelegt.
3. Will sich der Nutzer nun einloggen, gibt er Nutzername und Passwort an. Sein Passwort wird wieder gehasht und mit dem Hash verglichen, der in der Datenbank für seinen Nutzernamen abgelegt ist.
4. Stimmen die Hashes überein, wird der Nutzer eingeloggt, anderenfalls erhält er eine Fehlermeldung.

Die Fehlermeldung sollte hierbei immer nur sagen, dass die Zugangsdaten falsch sind. Wird angegeben, ob Passwort oder Nutzername falsch sind, kann der Angreifer daraus schon schließen, dass eines der beiden auf jeden Fall richtig ist. Deshalb sollten an dieser Stelle immer nur generische Fehlermeldungen ausgegeben werden.

Durch die obigen vier Schritte, sprich das Hashing der Passwörter, kann sichergestellt werden, dass beim Verlust der Datenbank bzw. einem Einbruch in die Datenbank nur die Hashes publik werden. Mittels der Hashes kann sich der Angreifer jedoch nicht einloggen, da diese in Schritt 3 ja erneut gehasht und somit nicht mehr mit dem Hash des eigentlichen Passworts übereinstimmen würden.

Warum sind Hashes nicht per se sicher?

Nachdem letzten Absatz könnte man meinen, (kryptografische) Hashes seien per se sicher. Man könnte fälschlicherweise annehmen, dass, unter Anwendung der vier Schritte aus vorherigem Absatz, die Passwörter ausreichend gesichert seien und man alles getan hätte, was zu ihrem Schutz nötig ist. Leider ist dem nicht so!

Zwar haben wir richtigerweise festgestellt, dass sich ein Hacker nicht (ohne Weiteres) mittels der Hashes einloggen kann, jedoch gibt es dennoch Möglichkeiten vom Hash wieder auf das Passwort zu schließen. Und da Nutzer (leider) meist dieselben Anmeldedaten für mehrere Portale/Webseiten nutzen, liegt die Wiederherstellung des Passworts im Interesse des Hackers. Deshalb betrachten wir nun, wie Hashes “entschlüsselt” (oder auch gecracked) werden können, um uns dann in einem späteren Absatz dann damit zu beschäftigen, wie wir eben dieses Risiko weiter eindämmen können.

Prinzipiell kann man zwischen zwei Methoden Hashes zu cracken unterscheiden:

1. Brute Forcing; Beim Brute Forcing (brute force = rohe Gewalt) wird versucht, durch Ausprobieren aller möglichen Kombinationen, das gesuchte Ergebnis zu erhalten. Hat man also z.B. den Hash “e22a63fb76874c99488435f26b117e37” so bildet man systematisch für alle Kombinationen eines Alphabets (z.B. A-Za-z0-9) den entsprechenden Hashwert und vergleicht diesen mit dem vorhandenen Hash. Sind die Hashes gleich, schaut man, welches die letzte Eingabekombination war und kennt somit das Passwort. Da das Durchprobieren aller Möglichkeiten einen hohen Rechen- und Zeitaufwand bedeutet, kann versucht werden zuerst mittels sogenannten “Dictionaries” zu arbeiten. Ein Dictionary (= Wörterbuch) ist eine Liste mit gängigen Passwörtern. Zu dieser Liste werden dann die Hashes erzeugt und mit dem gesuchten Hash verglichen. Je größer die gehackte Datenbank ist, umso wahrscheinlicher ist es, dass ein Nutzer eines der gängigen Passwörter aus dem Dictionary genutzt hat.
2. Lookup Tables; Um das Performance-Problem von Brute Force Attacken zu umgehen werden Lookup Tables genutzt. Eine Lookup Table ist eine spezielle Datenstruktur, die vorberechnete Passwort-Hash-Pärchen enthält. Das Besondere an Lookup Tables ist, dass sie selbst bei Datenbeständen von mehreren Millionen Pärchen immer noch mehrere hundert Abfragen pro Sekunde verarbeiten können. Lookup Tables sind also schneller als reines Brute Force, dafür sind sie durch die vorberechneten Werte ebenso wie Dictionary-Attacken auf eine vorbestimmte Eingabemenge (an Passwörtern) begrenzt. Eine Sonderform sind die sogenannten “Rainbow Tables”. Sie stellen eine Mischform aus Lookup Table und Brute Force Attacke dar. So ist ein Teil der Hashes vorberechnet, um zu bestimmen, ob sich der Hash eines Passwortes in einer Submenge befindet. Ist dies der Fall, wird die Submenge per Brute Force gehasht um das passende Passwort zu finden. Auf diese Weise können auf geringerem Platz mehr Hashes gespeichert und somit die Trefferrate erhöht werden.

Kommen wir nun dazu, warum wir Passwörter vor dem Hashen zusätzlichen Salten (= mit einem Salt versehen) sollten.

Nutzen von Salts beim Passwort Hashing

Mittels eines Salts lässt sich das im vorherigen Abschnitt beschriebene Lookup-Table-Verfahren außer Kraft setzen. Dies funktioniert, weil Lookup Tables davon ausgehen, dass das gleiche Passwort immer den gleichen Hash ergibt. Nutzen zwei User also das gleiche Passwort haben Sie normalerweise (wenn nur gehasht wird) den gleichen Hash.

Versieht man die Passwörter der einzelnen Nutzer nun aber mit einem zufälligen Salt, so ergeben die beiden Passwörter unterschiedliche Hashes, sodass eine Lookup Table nicht funktionieren kann, da vor dem Hack die Salts nicht bekannt sind und somit auch keine Lookup Table vorberechnet werden kann.

Brute Force Attacken sind hiervor jedoch immun. Bei ausreichend langen Passwörtern ist der Aufwand des Brute Forcing jedoch so hoch, dass das Entschlüsseln aller erbeuteten Passwörter nicht in annehmbarer Zeit erfolgen kann. Zudem kann durch Key Stretching das Brute Forcen weiter erschwert werden. (Mehr zu Key Stretching im nächsten Abschnitt.)

Best Practice: Passwort Hashing mit Salt

Bei der Verwendung von Salts sollten folgende Dinge beachtet werden, um eine maximale Effektivität zu erreichen.

• Der verwendete Salt sollte einzigartig pro Nutzer und Passwort sein. Das heißt, dass nicht nur bei der Registrierung eines Nutzers, sondern auch bei dem Wechsel seines Passworts ein neuer Salt generiert werden sollte.
• Der Salt sollte aus einer zufälligen Zeichenfolge bestehen. Zur Generierung des Salts sollte ein kryptografisch sicherer Zufallszahlengenerator (bzw. englisch cryptographically secure pseudo-random number generator; kurz: CSPRNG) verwendet werden. Dies ist wichtig, da nicht jeder Zufallsgenerator wirklich zufällig ist. So lassen sich bei vielen Standard-Generatoren Muster erkennen, anhand derer, bei großen Mengen an Zufallszahlen (in diesem Falle Salts), auf andere mit dem Generator erstellte Zahlen (Salts) geschlossen werden kann. In nachfolgender Liste (zum Aufklappen den Titel anklicken), finden sich gängige CSPRNG-Implementierungen für verschiedene Programmiersprachen.
• Liste mit CSPRNG-Algorithmen & Bibliotheken

  .NET (C#, VB, F#):	System.Security.Cryptography.RNGCryptoServiceProvider
  C/C++ (Windows API):	CryptGenRandom, ISAAC
  GNU/Linux/Unix-basierte Sprachen:	/dev/random oder /dev/urandom als Stream-Source nehmen
  Java:	java.security.SecureRandom, Java TRNG Client
  JavaScript:	RandomSource.getRandomValues(), CryptoJS
  Lua:	LuaCrypto, ISAAC
  NodeJS:	crypto.randomBytes()
  Perl:	Math::Random::Secure
  PHP:	mcryptcreateiv, opensslrandompseudo_bytes, php-csprng
  Python:	os.urandom, pyaes / Advanced Encryption Suite
  Ruby:	SecureRandom, drbg-rb
  Visual Basic:	ISAAC

• Weiter sollte der Salt mindestens so lang sein wie das Ergebnis der verwendeten Hash-Funktion. Wenn der Salt zu kurz ist, ergeben sich zu wenig Variationen, sodass der Angreifer trotz Verwendung eines Salts seine Lookup-Tables für alle Salt-Variationen in annehmbarer Zeit vorberechnen könnte.
• Das Hashing an sich sollte durch Erhöhung des Rechenaufwands künstlich verlangsamt werden. Mittels des Salts kann sichergestellt werden, dass Lookup Tables nutzlos werden. Gegen reine Brute Force Attacken helfen Salts jedoch nicht. Um auch Brute Forcing möglichst uneffektiv zu machen, sollte ein Hashing Algorithmus genutzt werden, der Key Stretching unterstützt. Key Stretching Algorithmen sind besonders rechenintensiv, sodass die Hashrate um einen frei definierten Faktor verlangsamt werden kann. (In der Regel erfolgt dies über die Angabe der Iterationen beim Aufruf der Hashing-Funktion.) Schafft eine Cracking Software bei einem normalen Verfahren z.B. 300.000 Hashs/Sekunde kann durch entsprechendes Key Stretching die Rate z.B. auf 5 Hashs/Sekunde verringert werden. Auf diese Art und Weise wird das Brute Forcen ineffektiv. Gängige Librarys zum Key Stretching sind zum Beispiel crypt(5), PBKDF2 oder bcrypt. Der Parameter beim Key Stretching sollte so gewählt werden, dass das Hashing möglichst langsam ist, schwache Geräte bzw. Webserver darunter aber nicht leiden. Wird mit zu vielen Iterationen gearbeitet, kann bei hohem Nutzeraufkommen zum Beispiel die Performance des Webservers leiden, auf dem die Hashing-Operationen ausgeführt werden.

Fassen wir also noch einmal kurz und knapp zusammen:

1. Der Salt sollte einzigartig pro Nutzer und Passwort sein
2. Der Salt sollte einem kryptografisch sicheren Zufallsgenerator entspringen
3. Der Salt sollte mindestens solang wie der Hash sein
4. Es sollte ein Key Stretching Verfahren angewendet werden

Unter Beachtung der obigen Regeln kann nicht mehr viel schief gehen. Dennoch schauen wir im nächsten Abschnitt noch einmal, was man beim Hashen und Salten definitiv nicht tun sollte.

Wie man Passwörter nicht hasht und saltet

Achtung – nachfolgende Dinge sollten beim Hashen und Salten von Passwörtern ausdrücklich nicht gemacht werden!

• Salts mehrfach verwenden; Wenn der Salt nur einmalig generiert wird und/oder im Quellcode hart codiert ist, dann verliert er effektiv an Nutzen. Durch einen hart codierten Salt würde das gleiche Passwort zweier Nutzer ebenfalls den gleichen Hash ergeben. Somit müsste die Lookup Table nur einmalig für den definierten Salt neu berechnet werden und der Schutz durch den Salt wäre ausgehebelt. Deswegen sollte ein Salt immer einmalig pro User und Passwort generiert werden.
• Nutzernamen als Salt verwenden; Das Verwenden des Nutzernamens als Salt ist eine ebenso schlechte Idee. Oftmals nutzen User denselben Nutzernamen für verschiedene Dienste. Würden nun alle Dienste den Nutzernamen als Salt verwenden, könnte ein gecracktes Passwort für sämtliche betroffene Dienste verwendet werden. Deshalb sollte ein kryptografisch sicherer, zufälliger Salt generiert werden.
• Einen zu kurzen Salt verwenden; Ist der Salt zu kurz gewählt, können Angreifer Lookup Tables für alle möglichen Salt-Variationen vorberechnen. Besteht der Salt zum Beispiel nur aus 2 ASCII zeichen, ergeben sich gerade einmal 95*95=9025 mögliche Salts. Selbst wenn man von einer großen Passwortliste von 20MB für eine Dictionary-Attacke ausgeht, ergibt dies (bei Berechnung der Liste mit allen Salts) gerade einmal eine Datenmenge von 176GB, deren Verarbeitung und Speicherung bei heutigen Maßstäben keine Problem mehr darstellt.
• Ausschließlich clientseitig hashen; Zwar scheint es auf den ersten Blick Sinn zu machen, das Passwort clientseitig, also zum Beispiel im Browser mittels Javascript, zu hashen, um das Passwort nicht im “Klartext” zum Server übertragen zu müssen, jedoch birgt dies bei genauerer Betrachtung mehrere Risiken. Zum einen kann nicht immer gewährleistet werden, dass der Browser des Nutzers JavaScript unterstützt und zum anderen hieße dies, dass nur noch der berechnete Hash an den Server geschickt und dort gegen den Hash in der Datenbank verglichen würde. Dies hieße auch, dass ein Angreifer beim Erbeuten des Hashs den Hash nicht mehr entschlüsseln müsste, sondern diesen direkt zum einloggen verwenden könnte, was eine große Schwachstelle darstellt. Das clientseitige Hashen und Salten kann also höchstens eine Zusatzleistung zum serverseitigen Hashen darstellen. Zudem sollte bedacht werden, dass clientseitiges Hashen kein Ersatz für eine sichere Verbindung (z.B. HTTPS TLS/SSL) zwischen Client und Server ist. Wer nur clientseitig hasht, aber keine sichere Transportstrecke nutzt, läuft Gefahr, dass der Hash mittels Man-in-the-Middle-Attacke abgegriffen und daraufhin missbraucht wird.
• Unsichere oder selbst geschriebene Hashing-Algorithmen verwenden; Auf einigen Internetseiten/-foren wird vorgeschlagen, zur “Verbesserung der Sicherheit” mehrere Hash-Funktionen zu kombinieren oder ein und dieselbe Funktion verschachtelt aufzurufen. Solche Vorschläge können zum Beispiel wie folgt aussehen: sha1(sha1(passwort)) oder md5(sha1(passwort)). Was hierbei oft vergessen wird, ist die Abschätzung von Nutzen und Kosten. Auf der Nutzen-Seite steht im Idealfall der minimal höhere Rechenaufwand. Dieser Ansatz ist jedoch mit einem iterativen Algorithmus (Stichwort: Key Stretching) wesentlich effektiver umzusetzen. Auf der Kosten-Seite steht das Risiko die Sicherheit zu schwächen oder Inkompatibilitätsprobleme hervorzurufen, sodass von solchen Methoden abgesehen werden sollte. Ebenfalls ist es keine gute Idee, seinen eigenen Hash-Algorithmus entwerfen zu wollen. Oftmals passieren hierbei Fehler, die wiederum die komplette Sicherheit infrage stellen. Etablierte Algorithmen hingegen sind zigfach getestet und wesentlich stabiler, sodass auf einen bereits etablierten Algorithmus zurückgegriffen werden sollte.

Weitere Sicherheitsmaßnahmen

Unter Anwendung der bisher in diesem Artikel gelernten Methoden – Hashing, Salting und Key Stretching – lässt sich bereits ein gut gesichertes System aufsetzen. Dennoch gibt es noch weitere Möglichkeiten, den Schutz der Passwörter zu erhöhen. Eine dieser Möglichkeiten ist das Verschlüsseln der Hashes.

Verschlüsselung von Hashes

Durch die Verschlüsselung von Hashes kann sichergestellt werden, dass Brute Force Attacken nutzlos werden. Bei einem Hack erhält der Hacker die Hashes in verschlüsselter Form. Erzeugt er nun Hashes, um diese mit den erbeuteten (vermeintlichen) Hashes zu vergleichen, wird kein Match finden, da er die von ihm erzeugten Hashes noch unter Anwendung des gleichen Schlüssels wie die Applikation verschlüsseln müsste.

Zur Verschlüsselung von Hashes eignen sich Lösungen wie AES oder HMAC. Damit dieses System funktioniert, sollte der Schlüssel (engl. secret) jedoch auf einem dedizierten System liegen bzw. die komplette Verschlüsselung auf eben diesem passieren. Liegt der Schlüssel/die Verschlüsselungslogik auf dem gleichen Server wie die Datenbank, ist es wahrscheinlich, dass der Angreifer auch hierauf Zugriff hat, sodass die Verschlüsselung ausgehebelt werden kann. Sollte es nicht anders gehen oder keine geeignete Hardware vorhanden sein, ist es jedoch immer noch besser die Verschlüsselungslogik auf dem gleichen Webserver wie die Datenbank zu implementieren als gar nicht zu verschlüsseln. Nichtsdestotrotz sollte abgewägt werden, ob die Sicherheitsansprüche es nicht gebieten, in solch einem Fall zusätzliche, dedizierte Hardware anzuschaffen.

Weiter sollte der Schlüssel für die Hash-Verschlüsselung während der Installation einer Instanz dynamisch erzeugt werden. Ein, in der Software fest hinterlegter, Schlüssel steigert das Risiko eines erfolgreichen Angriffs. Hat der Angreifer einmal Zugriff zum Code, könnte er bei einem fest hinterlegten Schlüssel alle Instanzen dieser Software attackieren. Hingegen er bei einem dynamisch generierten Schlüssel Zugriff auf jedes System haben müsste, dass er angreifen will.

Zeit-konstanter Hash-Vergleich

Bei der Implementierung des Hash-Vergleichs, also bei der Validierung des Passworts, sollte darauf geachtet werden, dass der Vergleich immer gleich lang dauert. Das meint, dass sowohl die Validierung eines gültigen Passwort Hashes als auch die Validierung eines ungültigen Hashes die gleiche Zeit beanspruchen sollten.

Die am häufigsten verwendete Methode zum Vergleich zweier Hashes dürfte wohl wie folgt (oder ähnlich) aussehen:

string hash1 = "e22a63fb76874c99488435f26b117e37";
string hash2 = "0a4ff18a7d23f8b3ded5eaf93104ac88";
if (hash1 == hash2) { 
  return true; 
}

Der “==”-Vergleichsoperator bewirkt jedoch, dass der Vergleich bei der ersten unterschiedlichen Stelle beendet und mit einem “false” quittiert wird. In obigem Beispiel wäre das direkt nach der ersten Stelle. Bei identischen Hashes hingegen würde der “==”-Operator alle Stellen der Hashes durchlaufen. Hieraus ergibt sich ein Zeitunterschied, den sich Angreifer zunutze machen können.

Attackiert der Angreifer einen Webservice und probiert alle Hashes für alle 256 Byte-Werte an der ersten Position des Hashes durch, kann er durch den Zeitunterschied feststellen, welches das richtige Byte an der ersten Position ist. Danach nimmt er sich die zweite Position vor und kann sich somit nach und nach an den richtigen Hash bzw. die richtige Eingabe herantasten.

Dieses Szenario mag auf den ersten Blick unwahrscheinlich klingen, ist jedoch technisch und praktisch umsetzbar, wie ein Paper der Universtität Stanford belegt.

Um diesen Angriffsvektor zu eliminieren, ist es nötig, eine Zeit-konstante Vergleichsroutine zu nutzen. Diese könnte wiederum wie folgt aussehen:

string hash1 = "e22a63fb76874c99488435f26b117e37";
string hash2 = "0a4ff18a7d23f8b3ded5eaf93104ac88";
bool valid = true;
if (hash1.Length == hash2.Length) 
{ 
  for (int i = 0; i < hash1.Length; i++) 
  { 
    if (hash1[i] != hash2[i]) 
      valid = false; 
  } 
} 
else 
{ 
  valid = false; 
} 
return valid;

In obigem Code wird in jedem Fall jede Stelle durchlaufen, unabhängig davon, ob die beiden Hashes gleich oder ungleich sind. Somit kann der Angreifer keine Rückschlüsse aus der benötigten Zeit auf die Richtigkeit seines Hashes erhalten.

Fazit

Auch wenn der Artikel nun etwas ausführlicher geworden ist, lässt sich festhalten, dass das Passwort Hashing und Salting kein “Hexenwerk” ist. Wenn man sich auf die wesentlichen Punkte begrenzt, ist es ohne großen Aufwand möglich, ein sicheres System zu implementieren. Und gerade weil es eben kein unüberschaubarer Aufwand ist, sollte man bei der Implementierung eines Login-/Passwort-basierten Systems auch immer die oben genannten Techniken wie Hashing, Salting und Key-Stretching einsetzen.

Über Feedback und Erfahrungen würde ich mich (wie immer) freuen. Wie implementiert Ihr euer Hash-System? Habt ihr Erfahrung mit Key-Stretching, Salting und den oben genannten Vorgehensweisen? Ist euer oder ein von euch betreutes System bereits einmal von einem Hack betroffen gewesen?