Salz und Hash in Datenbank speichern?

[mjustin]

Verstehe ich den Wikipedia Artikel richtig: Salt und Hash des Passwortes werden (in zwei Feldern) der Datenbanktabelle gespeichert? Meistens liest man ja, dass in der Datenbank nie der Klartext sondern ein Hash abgelegt wird. Mit dem Salt wären es dann zwei Felder in der Benutzertabelle.

[Mikkey]

Unter Salt ist nicht der Klartext des Passworts zu verstehen, sondern eine Zufallszeichenfolge, die mit dem eigentlichen Passwort verwürfelt den Hash ergibt.

[gammatester]

Wer spricht von Klartext? Das Salt wird mitgespeichert. Das ist ein öffentlicher Prefix für's Hashen und soll Dictionary-Attacken vermeiden (helfen).

[BUG]

Es entspricht zwar nicht der 1. NF, aber Salt und Hash können durchaus auch in einer Zeichenkette gespeichert werden.
Aber du solltest überlegen, ob du nicht lieber auf Adaptive Key Derivation Functions wie PBKDF2 oder bcrypt ausweichst.

[user0815]

Zu einem Passwort gehört ja auch ein Username, in der Datenbank werden somit Username + Passwort als Hash gesichert.

Username: Max Mustermann
Passwort: 12345

Der MD5 Hash von 12345 ergibt: 827ccb0eea8a706c4c34a16891f84e7b
Gibt man 827ccb0eea8a706c4c34a16891f84e7b in google ein so kann man sehen das dies der Hash zu 12345 ist.

Ein bisschen Salz dazu: c1a3f0b1c2530e5ed1f160e981ce776d

Passwort + Salz: 12345 + c1a3f0b1c2530e5ed1f160e981ce776d als MD5 Hash = 96f853c0ab69c35f2e40dede5a5e9d97

Username: Max Mustermann
Passwort: 96f853c0ab69c35f2e40dede5a5e9d97

Das Salz ist also nicht in der DB zu sichern, zumindest nicht offensichtlich.
Man könnte auch einen Hash bilden aus Username + Passwort + Salz + Length(Username) + usw…

Gibt der Username jetzt sein Passwort ein so muss der Hash wieder berechnet werden, stimmen berechneter Hash und gesicherter Hash aus der DB überein so stimmt das Passwort.

[Morphie]

Den Usernamen als Salt zu verwenden halte ich für eine schlechte Idee... Was, wenn Max Mustermann mal einen anderen Nachnamen annimmt? Der Username wird also geändert und das Passwort ist nicht mehr gültig...

[Phoenix]

Zitat:

Zitat von user0815 (Beitrag 1231391)

Das Salz ist also nicht in der DB zu sichern, zumindest nicht offensichtlich.

Doch.

idealerweise gibt es ja pro Datensatz einen eigenen Hash.
Hintergrund ist einfach, den Aufwand eines Angriffs hoch zu treiben. Haben alle Hashes den gleichen Salt (z.B. in der Config eines Programmes), so reicht es, das Dictionary einmalig zu salten und dann muss nur noch einmalig nach Matches gesucht werden. Heraus kommen alle User mit bekanntem Password.

Ist jedes Passwort mit einem eigenen Salt gehasht, so muss das Dictionary für jeden Datensatz mit dem jeweiligen Salt gehasht werden um dann nach Matches zu suchen. Im Prinzip muss man dann den Aufwand von oben pro Passwort treiben, was sich dann irgendwann nicht mehr lohnt.

[sx2008]

Sinnvollerweise speichert man zusätzlich noch eine Kennung für die Methode nach der man den Hash berechnet hat.

Code:

A=MD5 mit Salt
B,C,D=zukünftige Hashmethoden

Damit würde man in dem Datenbankfeld z.B. Folgendes speichern

Code:

A:12345:c1a3f0b1c2530e5ed1f160e981ce776d

Sollte die Hashmethode MD5 in Zukunft zu schwach gelten kann man verbesserte Hashfunktionen einsetzen.
Sobald sich ein Benutzer mit Passwort anmeldet kann man sogar im Hintergrund die Zeichenkette mit der besseren Methode abspeichern (Natürlich nur nachdem das Passwort erfolgreich mit der alten Methode überprüft wurde)

[user0815]

@Phoenix: Soll heissen ich erzeuge einen eindeutigen Schlüssel z.B. eine GUID:

Username: Max Mustermann
Passwort: 12345
GUID: {D365FA88-8442-40B3-82DC-E8D0E0EB0594}

DB Passwort: 12345 + {D365FA88-8442-40B3-82DC-E8D0E0EB0594} = MD5 Hash = dc8dcfc9fd656dca9365b4f7b5fe98f9

Und sichere in der DB das 'neue' Passwort + die GUID:

Username: Max Mustermann
Passwort: dc8dcfc9fd656dca9365b4f7b5fe98f9
GUID: {D365FA88-8442-40B3-82DC-E8D0E0EB0594}

[Morphie]

Zitat:

Zitat von user0815 (Beitrag 1231420)

@Phoenix: Soll heissen ich erzeuge einen eindeutigen Schlüssel z.B. eine GUID:

Username: Max Mustermann
Passwort: 12345
GUID: {D365FA88-8442-40B3-82DC-E8D0E0EB0594}

DB Passwort: 12345 + {D365FA88-8442-40B3-82DC-E8D0E0EB0594} = MD5 Hash = dc8dcfc9fd656dca9365b4f7b5fe98f9

Und sichere in der DB das 'neue' Passwort + die GUID:

Username: Max Mustermann
Passwort: dc8dcfc9fd656dca9365b4f7b5fe98f9
GUID: {D365FA88-8442-40B3-82DC-E8D0E0EB0594}

richtig.

Username: völlig egal!
Passwort: 12345 < Das wird NICHT gespeichert!
Random Salt: 54a4sd88asdasg54rwer7423
Hash: 62e83e4b82f0513deca5f0645f02804f < Das wird gespeichert!

Aus Sicht der Anwendung sieht das dann so aus:
1. Benutzer gibt Username und Passwort ein
2. Programm holt sich den Salt für den Benutzer aus der Datenbank
3. Programm generiert einen MD5-(oder was auch immer)-Hash mittels Passwort + Salt (im oberen Fall also 1234554a4sd88asdasg54rwer7423 = 62e83e4b82f0513deca5f0645f02804f)
4. Programm (oder Datenbank) prüft, ob der generierte Hash mit dem Hash aus der Datenbank übereinstimmt

Will man das System noch verbessern, kann man das Passwort mehrmals salzen (z.B. Salt + Password + md5(Salt))