Man darf nur einen Fehler nicht machen: einen kurzen Salt-Wert verwenden.
richtig, das geht Hand in Hand mit "nicht wiederholen". Denn wenn man als Salt eine Zufallsziffer (0-9) nimmt hat man in seiner Userdatenbank eine Menge Wiederholungen ^^
Annahme das Passwort ist "12345" und der Salt-Wert ist "foo" - dann ist die Kombination (bei einer einfachen Verkettung) 12345foo und so ein Wert wird ziemlich sicher in einer Rainbow-Table "aller" 8-stelligen Passwörter drin stehen.
Oben habe ich behauptet "alle geht nicht", aber
ich habe gerade überlegt ob bei acht Zeichen wenn man Sonderzeichen mal weg lässt kommt man ohne Wörterbuch auf rund ((26+26+10)^8 =) 2,2*10^14 mögliche Zeichenfolgen. Ich denke dass das ein Index ist, der noch im Rahmen des verkraftbaren und durchsuchbaren liegt.
f12o34o5 wäre also wohl genauso schlecht
Das Paradoxe ist, dass selbst das Hashen eines einzelnen Buchstabens mit einem Hash-Algorithmus wie MD5 dessen Entropie erhöht obwohl die Information eigentliche dieselbe ist. Aber anstatt 8 Bit hat man nun 128 Bit mit denen man hantieren muss.
Ja... jain äääh naja. Also wenn der Algorithmus bekannt ist und er sollte ja bekannt sein (keine Security by Obscurity) dann ist die Menge der möglichen hashes für einzelne Buchstaben ja recht begrenzt und oben schrieb ich ja dass sie sich nicht wiederholen mögen.
Ein Angreifer könnte also "einfach" (naja *räusper*) eine Tabelle nehmen/erstellen, in der der bekannte Salzgehalt vorhanden ist.
theoretisch sind Hashes tatsächlich nicht sooo gut geeignet als Salz, weil die Menge ihrer unterschiedlichen Zeichen typischerweise bei 16 liegt.
Aber lieber 16 hoch (Länge eines Hashwertes als String) als 62 hoch 1 :D
Eine weitere Möglichkeit ist es auch einfach einen Hash nochmal zu hashen - das macht ein einzelnes schlechtes Passwort aber auch nicht sicherer.
Du meinst etwa so:
hash('sha512',md5($passwort).$passwort;
?
Ja, warum nicht? ^^ wobei... auch da ist die Tabelle relativ leicht zu erstellen (wenngleich dennoch groß), weil die Beziehung welches PW zu welchem Salz gehört bekannt ist. Bei dem was ich vorher vorschlug, nämlich den Usernamen zu nehmen ist diese Beziehung nicht bekannt, man kennt zwar den Usernamen und dessen Hashwert, muss aber alle Usernamen-Hashes mit allen Wörterbuch-PWs kombinieren. Andernfalls würde man alle Wörterbuch-PW-Hashes mit sich selbst (nicht mit allen!) kombinieren, was eine viel kleinere Tabelle ergibt.
Kurz: Wir denken binär und haben zwei PW-Stellen. Mein Hash XORt mit 1.
mögliche PWs:
00
01
10
11
4 Stück
mögliche PWs mit Hash des PW:
PW Hs
00 11
01 10
10 01
11 00
4 Stück
mögliche PWs mit Hash des einstelligen Usernamens:
PW Hs
00 0
00 1
01 0
01 1
10 0
10 1
11 0
11 1
8 Stück... weil ich eben nicht weiß welcher Username zu welchem PW gehört (bei einstelligen binären Benutzernamen ist die Anzahl der User allerdings auch so scheißklein, dass man das Projekt aufgeben sollte :D)
Die Beziehung zwischen Account und Salt darf bekannt sein, die Beziehung zwischen PW (unabhängig davon für welchen Account) und Salt möge unbekannt sein.
sh:( fo:| ch:? rl:( br:& n4:& ie:{ mo:} va:) de:µ_de:] zu:) fl:( ss:| ls:[ js:(