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

Der 4. und vorletzte Teil zum Thema Passwörter richtig speichern.
Wir bauen auf unseren Erkenntnissen aus den vorangegangenen Teilen auf.

Blowfish / Twofish und BCrypt

Sind Algorithmen wie SHA und MD5 auf Geschwindigkeit ausgerichtet, verfolgen Algorithmen wie Blowfish / Twofish und BCrypt (folgend zur Vereinfachung unter dem Sammelbegriff BCrypt zusammengefasst) einen anderen Ansatz. Das Hashing soll so aufwändig und teuer wie möglich sein.

Um es direkt in den rechten Kontext zu setzen: in normalen Anwendungsfällen fällt diese Verlangsamung nicht merklich ins Gewicht. Erst wenn viele Berechnungen hintereinander erfolgen, wird die Berechnung spürbar langsamer als bei SHA oder MD5.

BCrypt implementiert einige, für uns essenzielle, Eigenschaften, die uns unserem Ziel sehr nahe bringen. Es werden Rechenoperationen verwendet, die CPU optimiert sind. Damit sind die GPUs der Grafikkarten nicht relevant für das Hashing.

Darüber hinaus ist der Kostenfaktor fester Bestandteil des Algorithmus. Er kann von uns selber angegeben werden. Der Kostenfaktor beschreibt die Anzahl der Hash-Iterationen für die Generierung des Salt. Der Kostenfaktor muss zwischen 4 und 31 liegen. Standard ist 6. Der Kostenfaktor (k) beschreibt 2^k Iterationen über den Salt.

Schlussendlich fordert BCrypt 4kb Arbeitsspeicher vom System an. Dies erschwert eine Hardware-Optimierung für das Cracken von BCrypt.

BCrypt implementiert die Generierung eines Salt je Passwort selber und Kodiert diesen eigenständig in den Hash. Entsprechend müssen wir den Salt nicht selber vorhalten. Wir bekommen diese Funktion quasi geschenkt.

Durch dieses Feature ergibt sich eine spezielle Signatur, des Hash-Wertes ab welcher sich erkennen lässt, das es um einen BCrypt Hash handelt:

$2y$10$cNAgaBaW4WnIjL6Vp6qyYeLcOFyd./tQbEoclWaigoYj1JTIvvmye

Die einzelnen Segmente sind durch das $-Zeichen voneinander getrennt.
Das rote Segment beschreibt den verwendeten Hash-Algorithmus.
Es exitieren aktuell drei Varianten:

  • 2a
  • 2x
  • 2y

 

Im Algorithmus 2a ist ein Fehler in der genutzten Blowfish-Implementierung gefunden worden und entsprechend als unsicher gekennzeichnet. Dieser Modus sollte entsprechend nicht mehr genutzt werden.

Der Algorithmus 2y korrigiert den Fehler aus 2a und gilt als sicher. Dieser Modus wollen wir verwendet.

2x stellt ein Bindeglied von 2a und 2y dar. Dieser Modus korrigiert den Fehler von 2a ist aber noch kompatibel mit den 2a Hashes. Dieser Modus sollte nur verwendet werden, wenn bereits Hashes mit 2a erzeugt wurden und nicht geändert werden können.

Das blaue Segment stellt den Kostenfaktor dar, welcher verwendet wurde, um den Salt zu berechnen.

Der grüne Bereich beinhaltet den Salt und den Passwort Hash, wobei der hellgrüne Bereich der Salt ist und der dunkelgrüne Bereich dar eigentliche Passwort-Hash.

Dies ergibt eine Gesamtlänge von 60 Zeichen (in der String-Repräsentierung).

Da in den 60 Zeichen alle Informationen untergebracht werden müssen, reduziert sich die maximale Zeichenlänge, die für das eigentliche Passwort zur Verfügung steht auf maximal 55 ASCII-Zeichen. Dies kann je nach Implementierung von BCrypt variieren, wobei eine Mindestlänge von 50 garantiert ist. Wird ein alternativer Zeichensatz wie UTF-8 verwendet, reduziert sich u.U. die Anzahl der zur Verfügung stehenden Zeichen.

Überschreitet ein Passwort die maximale Länge, wird das Kennwort am Ende abgeschnitten.
50 Zeichen für ein Passwort sollten für die meisten Anwendungsfälle genügen.
Allerdings können sich zwei Probleme mit der Limitierung auf 50 Zeichen ergeben:

  1. Möchten wir neben dem Salt auch noch ein wenig Pepper dazugeben, reduziert sich die Anzahl an möglichen Zeichen dramatisch.
  2. Der Trend geht weg von Passwörtern hin zu Passphrasen, die schnell eine Länge von 50 Zeichen überschreiten können. Vor allem in Kombination mit Pepper dürfen die Phrasen demzufolge nicht lang sein.

Darüber hinaus gibt es von BCrypt keine native Implementierung von Microsoft im .NET Framework. Entsprechend ist man auf die Nutzung von Dritthersteller-Bibliotheken angewiesen.

Hier sei auf einen wichtigen Grundsatz aus dem Bereich der Kryptographie hingewiesen:

Implementiere kryptographische Algorithmen nicht selber! Greife auf bestehende, getestete Implementierungen zurück und nutze diese.

Christian Rehn
(http://www.christian-rehn.de/2012/06/12/warum-man-krypto-nicht-selbst-machen-sollte/)

Vorteil
+ kein separater Salt nötig
+ keine GPU Unterstützung
+ dynamischer Kostenfaktor

Nachteil
– Passwortlänge ist auf max. 56 Byte begrenzt
– zusätzliche Härtung durch Pepper schwierig
– keine native Implementierung in .NET

Fazit
BCrypt bietet uns eine breite Palette an Features, die wir uns für einen gehärteten Passwortspeicher wünschen. Die Verwaltung von Salts wird uns abgenommen, hardwareoptimiertes Cracking wird aktiv erschwert, der Kostenfaktor kann angepasst werden, ohne die Implementierung ändern zu müssen.

Allerdings darf nicht verschwiegen werden, dass aktuell keine Implementierung innerhalb des .NET Frameworks gibt und die Anzahl von Stellen für das Passwort limitiert ist.

Prinzipiell sind wir bereits mit der Nutzung von BCrypt ziemlich gut aufgestellt und falls wir die genannten Limitierungen in Kauf nehmen können, dann können wir BCrypt ohne weiteres einsetzen.

 

Beispiel
Für dieses Beispiel wird die Bibliothek CryptSharp 2.1 (http://www.zer7.com/software/cryptsharp) von James F. Billinger verwendet.

Achtung
Die Bibliothek wurde nicht auf Korrektheit der Implementierung geprüft. Deshalb dient dieses Beispiel nur zu Demonstrationszwecken. Die Nutzung der Bibliothek ist nicht als Empfehlung für die Verwendung in kritischen Systemen und Umgebungen zu verstehen.

 

Download

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

tl;dr

BCrypt bietet uns bereits einen sehr guten Ansatz zum sicheren Hashen von Passwörtern. Aktuell ist BCrypt meiner Meinung nach die beste Wahl – sofern die Implentierung vertrauenswürdig ist.

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.