|
Salt (deutsch Salz) bezeichnet in der Kryptographie eine zufällig gewählte Zeichenfolge, die an einen gegebenen Klartext vor der Verwendung als Eingabe einer Hashfunktion angehängt wird, um die Entropie der Eingabe zu erhöhen. Es wird häufig für Speicherung und Übermittlung von Computer-Passwörtern benutzt.
Wikipedia
string salt = "mySalt"
return hashFn(salt + "geheimnis")
string myHash = hashFn("geheimnis")
for(int i=0; i<(2^12); i++){ //2^12 = 4096 Runden
myHash = hashFn(myHash)
}
return myHash
//Beispiel:
// 1$12$MySALT$DerEigendlicheHash
//Erklärung:
// Index für MD5$Anzahl Runden (2^12 = 4096)$Salt$Hash
string salt = "mySalt"
string myHash = hashFn(salt + "geheimnis")
for(int i=0; i<(2^12); i++){
myHash = hashFn(myHash)
}
return myHash
string salt = "mySalt"
string myHash = hashFn(salt + "geheimnis")
for(int i=0; i<(2^12); i++){
myHash = hashFn(salt + myHash)
}
return myHash
Die Rainbow Table (zu Deutsch: Regenbogentabelle) ist eine von Philippe Oechslin entwickelte Datenstruktur, die eine schnelle, probabilistische Suche nach einem Element des Urbilds (i. d. R. ein Passwort) eines gegebenen Hashwerts ermöglicht. Der sogenannte Time-Memory-Tradeoff gestattet die Suche nach fast allen Klartexten eines bestimmten Zeichenraums innerhalb einer erheblich kürzeren Zeit, als diesen komplett zu bruteforcen und ohne alle für diesen Zeichenraum möglichen Hashwerte speichern zu müssen.
Dieses funktioniert bei Hashfunktionen ohne Salt, wie es z. B. bei den Passwörtern für die Windows-Familie oder vielen Routern der Fall ist. Vergleichsweise umfangreiche Tabellen wurden für LM Hashes und MD5 berechnet und stehen aus diversen Quellen zur Verfügung.
Verwendung finden Rainbow Tables bei der Wiederherstellung von Passwörtern, innerhalb der IT-Forensik, bei Penetrationstests und beim illegitimen Passwortcracken.
Rainbow Table
string runden = 2^12
string myKey = MD5("geheimnis", "salt", runden )
string[] keys = new string[){ myKey, "geheimnis", "salt" }
string myCryp = "meine super geheimen daten"
for(int i<0; i<runden; i++){
myCryp = AES(myCryp, keys[i % 3]) //AES(string, key)
}
return myCryp
|
2 |
Sehr schöne und ausführliche Darstellung. +1!
– ffordermaier 25.07.2011
|
|
1 |
Gute Erklärung. Aber: Geht das nicht am Thema vorbei? Wenn ich den OP richtig verstanden habe, wollte er doch wissen, wie er Passwörter speichern kann, die er später wieder im Klartext erhält um sich bei einem Dienst automatisch anmelden zu können.
MD5 & Co sind, soviel wie ich weiß, eine Einbahnstraße. Aus einem MD5 Hash kann ich das ursprüngliche Passwort doch nicht wieder herstellen? Sie dienen lediglich dazu, ein eingegebenes Passwort gegen ein gespeichertes validieren zu können. – Andreas Richter 25.07.2011
|
|
Aus eben diesem Grund besteht mein Artikel auch aus 2 Teilen (den zweiten Teil hatte ich nachträglich hinzugefügt da ich hier auf Arbeit bin und mir kurz was dazwischen gekommen ist :D). Da bei diesem Thema sowohl die verfahren der symetrischen Verschlüsselung, als auch der asymetrischen eine Rolle spielen (Speicherung des Masterkennworts zu Authenfifizierungszwecken als Hash, Speicherung der Geheimen Daten als symetrische Verschlüsselung) und beide Verfahren a) Verwand und b) in diesem Fall kombiniert werden können, hab ich mich für eine etwas ausführlichere Betrachtungsweise entschieden.
– Floyd 25.07.2011
|
||
Ich muss aber zugeben das der asymetrische Teil vielleicht etwas zu ausführlich geworden ist. Im Eifer des Gefechts hab ich einfach nur geschrieben, geschrieben und geschrieben :D
– Floyd 25.07.2011
|
||
Ok. Den zweiten Teil habe ich vor meinem Kommentar nicht gesehen. Hast du den nachträglich eingefügt bzw. ergänzt?
– Andreas Richter 25.07.2011
|
||
Vielen Dank für deinen ausführlichen Beitrag. Der erste Teil des Beitrags trifft, wie Andreas Richter es bereits angemerkt hat, auf meine Frage nicht ganz zu, da man aus dem Hash nicht auf das ursprüngliche Passwort schließen kann (und das ist ja auch gewollt).
– wlami 25.07.2011
|
||
Bei der symmetrischen Verschlüsselung (Teil 2) stimme ich Dir vollkommen zu. Ich ordne dieses Vorgehen unter meinem 1. Punkt an (Passwort mit einem Passwort absichern) Allerdings sehe ich hier das Problem, dass die Verschlüsselung nur so gut ist wie der Key. Und ein sicheres Passwort (Buchstaben, Groß und Klein, Zahlen, Sonderzeichen) mit einem Smartphone einzugeben ist ein Krampf. Deshalb habe ich nach Alternativen gefragt :)
– wlami 25.07.2011
|
||
Und genau an diesem Punkt setzt mein erste Teil des Beitrags an.
Im Zweiten Teil bin ich gesondert auf das Thema Nutzerpasswörter eingegangen und wie man, mit hilfe asymetrischer Verschlüsselungsverfahren, aus den unzureichenden Nutzerpasswörtern, sichere Keys erzeugen kann. Zitat: – Floyd 25.07.2011
|
||
"Sinnvoll ist es vorallem nicht das von Nutzer gewählte Passwort [...] für den Cryp-Algorithmus zu verwenden, sondern selbiges mit den oben beschriebnen Verfahrfahren der Einwegverschlüsselung zu Verschlüsseln. In der Regel sind Nutzerpasswörter recht einfach gestrickt weshalb dieses im Schnitt eine Länge von 6-9 Zeichen aufweisen. Zu wenig um als sicherer Key für einen symetrischen Cryp-Algorithmus zu dienen. Ein MD5-Hash zum Beispiel hat dagegen 128-Bit und ist somit deutlich besser geeignet."
– Floyd 25.07.2011
|
||
Das Problem, was ich hier sehe ist der Werte-Raum, der für die Generierung des Keys verwendet wird: wenn ich z.B. eine vierstellige Zahl als Benutzereingabe erwarte und daraus einen Hash berechne, dann ist der Hash zwar ein guter Key. Die Menge der möglichen Hashes ist aber durch die Menge der Originaleingaben beschränkt.
Ein Hash auf eine kurze Eingabe macht das Passwort nicht sicherer, da der Angreifer die Generierung des Hashes nachvollziehen kann und dann den begrenzten Original-Passwortraum ausprobieren kann. An dieser Stelle empfinde ich deinen Vorschlag eher als Obscurity als Security. – wlami 25.07.2011
|
||
1 |
Natürlich du recht das bei einem Werteraum mit maximal 9999 Kombinationsmöglichkeiten ist kein Passwort sicher, und wird es auch nie werden. Egal wieviel Aufwand du rein steckst.
Durch die Verwendung eines Salts den du nicht direkt in oder an der verschlüsselten Datei ablegst kannst du einem einfachen Datenklau aber entgegenwirken da die Anzahl der Kombinationsmöglichkeiten jetzt auch noch von der Qualität deines Salts abhängt. Durch die ausreichend hohe Anzahl der Runde ist es nun nicht mehr möglich ohne wissen des Salts alle Kombinationsmöglichkeiten auszuprobieren. – Floyd 25.07.2011
|
|
1 |
Die Runden verlängern zusätzlich den technischen Aufwand der für eine Entschlüsselung betrieben werden muss. Wenn du zum Beispiel deinem Nutzer eine Entschlüsselungszeit von 2 Sekunden zumuten kannst, beträgt die Entschlüsselungszeit bei bekanntem Salt+Passwort immerhin schon 5,5 Stunden. Nicht viel aber besser als garnichts. Wichtig ist vorallem des du den Wertebereich des Passworts erweiterst. Auf mind. 6-9 Alphanumerische Zeilen.
– Floyd 25.07.2011
|
|
|
Diese Vorgehensweise ist auf jedenfall zu empfehlen. Um das Passwort noch sicherer zu machen sollte man noch zusätzlich [url=http://de.wikipedia.org/wiki/Salt_%28Kryptologie%29]"Salt"[/url] verwenden.
– michael2011 25.07.2011
|
||
Auch hier: Ist das nicht am Thema vorbei? Hashes sind eine Einbahnstraße. Aus einem Hash kann ich das ursprüngliche Passwort nicht wieder herstellen.
Wenn ich den OP richtig verstanden habe, möchte er aber genau das. Auf dem mobilen Device soll z.B. das Passwort für seinen EMail-Account gespeichert werden, mit dem sich seine EMail-App am Server anmelden kann. In diesem Szenario ist MD5 & Co. nicht die richtige Wahl. – Andreas Richter 25.07.2011
|