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

Im 5. und letzten Teil der Serie zum Thema Passwörter richtig speichern führen wir unsere Erkenntnisse aus den letzten Teilen zusammen und ziehen ein allgeimeines Fazit zu dem gesamten Themenkomplex.

BCrypt mit Pfeffer

Im Abschnitt zu MD5 und SHA haben wir über den durchaus sinnvollen Einsatz von Pepper gesprochen, jedoch wird im Abschnitt zu BCrypt in Kauf genommen, dass wir keinen Pepper mehr verwenden, um die limitierte Anzahl der Passwort-Zeichen nicht noch weiter zu reduzieren.

Wir können beide Ansätze miteinander kombinieren, in dem wir einen zweistufigen Prozess etablieren.

Wir verwenden zunächst einen Hash Algorithmus mit maximal 256Bit. Mehr Bit machen keinen Sinn und sind eher kontraproduktiv, da wir höchstens 50 Zeichen sinnvoll im BCrypt Algorithmus verwenden können.

Hier bieten sich SHA256 oder SHA3 mit 256Bit Tiefe an.

Für SHA3 gibt es aktuell keine native Implementierung im .NET Framework. Entsprechend müssen wir auch hier auf eine SHA3 Bibliothek von einem Dritthersteller zurückgreifen.

Wer das nicht möchte, der kann genauso gut SHA256 verwenden, welcher auch als sicher gilt (https://web.archive.org/web/20150315061807/http://csrc.nist.gov/groups/STM/cavp/documents/shs/sha256-384-512.pdf).

Zunächst kombinieren wir unser Passwort bzw. unsere Passphrase mit unserem Pepper.
Dies wird dann mit SHA3 oder SHA256 gehashed.
Dieser Hash dient als Eingabe für unsere BCrypt Funktion.
Das Ergebnis wird anschließend in der Datenbank abgelegt.

Bei SHA2 und SHA3 Hashes gibt es keine Längenbeschränkungen im relevanten Bereich und die Wahrscheinlichkeit von Kollisionen ist vergleichsweise gering. Hier kann von genügend Entropie ausgegangen werden, wenn eine Grenze erreicht werden sollte, so dass dennoch unterschiedliche Hashes errechnet werden.

 

Vorteil
+ weitere Hürde für Angreifer durch Pepper
+ keine Limitierung für Passwortlänge

Nachteil
– Aufwändiger zu implementieren
– keine native Implementierung in .NET

Fazit
Die Kombination aus BCrypt und Pepper bietet den besten Schutz für unser Ausgangsszenario. Auch wenn es keinen absoluten Schutz gibt – spätestens bei den Quantencomputern haben wir ein großes Problem – bieten BCrypt + Pepper aktuell den besten Schutz, sofern das Pepper ordentlich geschützt ist und ein ausreichender Kostenfaktor gewählt wurde.

 

Beispiel
Für dieses Beispiel werden die Bibliotheken CryptSharp 2.1 (http://www.zer7.com/software/cryptsharp) von James F. Billinger und SHA3 (https://www.nuget.org/packages/SHA3/) von Joey Dluzen   Bertoni,  Daemen,  Peeters,  und Van Assche verwendet.

Achtung
Die Bibliotheken wurden nicht auf Korrektheit der Implementierung geprüft. Deshalb dient dieses Beispiel nur zu Demonstrationszwecken. Die Nutzung der Bibliotheken 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-Teil5-BCryptNPepper.git

Was tun im Worst-Case

Wenn BCrypt mit einer speziellen Payload zu unsicher geworden ist, dann kann man relativ einfach die Payload erhöhen. Hier muss dann während der Anmeldung eines Benutzers eine Routine greifen, die im Falle einer positiven Authentifizierung das Passwort aktualisiert, indem es neu verschlüsselt wird.

Dies ist kein unwahrscheinliches Szenario, da Anwendungen meist über Jahre, wenn nicht Jahrzehnte leben und in der Zeit die Hardware ihre Leistung verzigfacht.

Entsprechend muss dann nachgesteuert werden.

 

Fazit

Absoluten Schutz gibt es nicht. Auch die hier aufgezeigten Möglichkeiten Passwörter zu härten bieten keinen 100% Schutz vor Crackern. Aber wir haben Wege herausgearbeitet, das Cracken von Passwörtern so teuer und schwer wie aktuell möglich zu machen. Damit werden viele Angriffsvektoren de facto uneffektiv und unattraktiv.

Mit Verwendung des BCrypt-Algorithmus sind wir im Rahmen für die Zukunft gewappnet, wenn die Hardwareleistungen der Systeme steigen und wir gezwungen sind die Sicherheit zu erhöhen.

Wir haben in diesem Artikel lediglich den Fall betrachtet, dass ein Angreifer Zugriff auf unseren Datenbestand hat. Attacken über sog. Passwort-Guessing via Social Engineering sind natürlich nach wie vor möglich. Hier steht und fällt die Sicherheit mit der Komplexität des Passworts des Benutzers und seiner Medienkompetenz dieses nicht herauszugeben.

Auch Szenarien wie Keylogger auf dem System, unverschlüsselte Übertragung zwischen Browser / Client und Server, sowie Man-In-The-Middle- und SSL-Forgery Attacken bleiben immer noch eine reale Gefahr.

Kennt der Angreifer bereits mein Kennwort, brauche ich den Aufwand für das Knacken der Datenbank nicht mehr zu betreiben, sondern ich melde mich ganz einfach am System mit meinen ergaunerten Zugangsdaten an.

tl;dr

Benutzt Pepper + BCrypt mit einer entsprechend hohen Kostenfaktor, um bei einem Datenbestandsverlust so sicher wie möglich zu sein.

Ladet euch das kompositorische Beispiel auf GitHib herunter:
https://github.com/christianaschoff/Passworte-AlleBeispieleUndMehr.git

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
Nächster Beitrag >>

Schreibe einen Kommentar

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