Salting von Hashwerten?

ascer

Captain
Registriert
Juni 2008
Beiträge
3.858
Huhu Community,



die grundlegende Funktion der Hashwertbildung ist mir bekannt, ebenso einige gängige Praktiken. Mir ist allerdings nicht ganz klar, wie das mit dem Salzen funktioniert.

Nehmen wir an, ich habe mein Passwort P und mein Salt S. Muss ich dann S in Klartext z.B. in einer Datenbank speichern, zwecks Vergleich später?

Ich meine, ich kann ja schlecht eine Lösung implementieren, wo P mit S gesalzen und dann die Hashwertberechnung durchgeführt wird, da ich aufgrund der willkürlichen Berechnung von S ja den korrekten Hash später nicht wieder bekomme.

Irgendwo müsste ich S ja dann also in Klartext aufbewahren? Oder wie würde das sicherer gehen?



Grüße

ascer
 
Du packst den Salt einfach dort hin, wo das Passwort auch steht.
 
Aber dann würd ich doch nie wieder den richtigen Hash bekommen?


Als Beispiel:
Der User gibt doch nur sein Passwort "abc" ein, der Salt "asdva43w6q32" wird automatisch dazu generiert und alles zusammen kommt in eine Hashfunktion damit ich hinterher einen Hashwert habe. Oder hab ich da was im Ansatz unterschlagen?!

Um später aber einen korrekten Login zu bestätigen, benötige ich doch den gleichen Hashwert, also muss ich doch das vom User eingegebene "abc" erneut mit dem Salt "asdva43w6q32" zusammenführen. Der Salt darf diesmal ja nicht zufallsgeneriert sein, ich benötige ja exakt ""asdva43w6q32" um wieder mit "abc" zusammen auf den korrekten Hashwert zu kommen.

D.h. ich muss doch irgendwo den Salt in Klartext speichen?!
 
Im Normalfall packst du das Salt zum Hash.
Achte unbedingt darauf, pro user und pro passwort neue Salts zu nehmen.
Dadurch sollten für gleiche Passwörter unterschiedliche Hashes entstehen.

http://crackstation.net/hashing-security.htm

Im besonderen der Abschnitt: "How to Hash Properly".

Hier findest du eigentlich eine sehr gute Dokumentation und wie das ganze ablaufen sollte...sowohl erklärt als auch mit Codebeispiel für PHP, Java, ASP.NET oder Ruby...

Wenn dann noch Fragen bestehen, einfach melden ;-)
 
Du nimmst nen Seperatro im Paswort Feld oder nen Extra Feld SALT
Und ja dass muss man. Der Salt ist ja auch unkritisch. Er sorgt nur dafür, dass alle User mit dem selben Passwort immer noch erschiedene Hashes haben
 
Der Salt wird in der Datenbank gespeichert, zusammen mit dem Hash. Im Sinne der Sicherheit ist das kein Problem, denn der Salt soll ja vor allem dafür sorgen, den Hash vor Rainbow-Tables-Angriffen zu schützen - also davor, dass ein Angreifer, dem der Hash in die Hände fällt, nicht einfach in einer fertig berechneten Tabelle nachschlagen kann, wie der Klartext lautet. Wenn diese Möglichkeit ausscheidet, dann hilft auch die Kenntnis der Salts dem Angreifer nicht beim "Knacken" des Hashes.
 
ascer schrieb:
Aber dann würd ich doch nie wieder den richtigen Hash bekommen?
Wie meinst du das? Du packst den Salt, so wie er ist, unverschlüsselt, ungehasht, ungesichert, einfacher plain-text mit zum Passwort in die Nähe. Du hashst immer in der Weise hash( hash( Passwort ). Salt ) o.ä. Beim Erzeugen wirfst du ihn rein, wie er raus kommt und speicherst ihn genau so in die DB. Genauso holst du ihn dann auch beim Login und hashst damit wieder mit dem eingegebenen Passwort und wenn es stimmt, kommt der Hash raus, der in der Passwort-Spalte steht.
ascer schrieb:
Der User gibt doch nur sein Passwort "abc" ein, der Salt "asdva43w6q32" wird automatisch dazu generiert und alles zusammen kommt in eine Hashfunktion damit ich hinterher einen Hashwert habe. Oder hab ich da was im Ansatz unterschlagen?!
Ganz genau. Einfach der Hash-Funktion mit dem Passwort unterschieben.
ascer schrieb:
D.h. ich muss doch irgendwo den Salt in Klartext speichen?!
Exakt. Und wie gesagt: direkt mit zum Passwort, unverschlüsselt, nicht gehasht oder sonstiges. Das Ding ist nicht geheim oder sonstiges, es dient rein gegen Rainbow Tables. Ein Salt sollte nur anderen Salts gegenüber einzigartig sein und keiner sollte doppelt auftreten, dann passt das System.

Besser wäre, wenn du gleich auf eine Lib setzt, wie z.B. diese. bcrypt packt den Salt gleich mit in den resultierenden String und ist außerdem sicherer.
 
Kurz und knapp: Ja, der Salt wird im Klartext gespeichert.
 
Super, alles klar, vielen Dank! :)

Das hat jetzt definitiv die Erleuchtung gebracht! :)

Zusätzlich werd ich mir mal noch bcrypt und crackstation.net die Tage angucken :)
 
Yuuri schrieb:
Wie meinst du das? Du packst den Salt, so wie er ist, unverschlüsselt, ungehasht, ungesichert, einfacher plain-text mit zum Passwort in die Nähe.
Kannst du mir mal eine Definition von Entfernung geben, im Kontext von Speichern in Datenbanken?
 
F_GXdx schrieb:
Kannst du mir mal eine Definition von Entfernung geben, im Kontext von Speichern in Datenbanken?
Wenn du den DB-Eintrag als Array ausliest hat jede Spalte am Ende ja einen Index... Die Differenz der Array-Indizes ist dann der Abstand. Die Werte müssen >=1 sein....
 
Daaron schrieb:
Wenn du den DB-Eintrag als Array ausliest hat jede Spalte am Ende ja einen Index... Die Differenz der Array-Indizes ist dann der Abstand. Die Werte müssen >=1 sein....

in Bcrypt ist der Salt in den Hash eingebaut, damit wäre der Arrayabstand = 0 :p :lol:
 
Ich würde auch stark dazu raten, da nichts selbst zu implementieren sondern bestehende Verfahren im Rahmen einer Library (bcrypt, scrypt etc. - einfach verwandte Wikipediaartikel durchforsten) zu verwenden.
Falls es natürlich nur um's Verständnis geht: gesalzen kann lokal und oder global werden. Ideal wäre z.B. beides, also ein statischer globaler salt der z.B. nicht gleich direkt irgendwo steht sondern teils sogar in den Server einkompiliert wird (dann müsste ein Angreifer schon mal erst deine Serverbinaries mitkopieren). Natürlich auch nicht immer zu 100% sicher aber besser als nix. Lokalen Salt (also pro Passwort) kannst du auch ruhig offen abspeichern, eventuell sehr schwach obfuscated (z.B. im Passwort verwendeter salt = SHA256(angegebener String) ). Das Ganze kann z.B. so aussehen:

GLOBALSALT987
User1 - SALZ1234:PASSWORTHASH0987654321

Hash(GLOBALSALT987 + SALZ1234 + Passwort) = PASSWORTHASH0987654321
 
alles klar, danke :)
 
Zurück
Oben