nicht angemeldet
Hi,
»» ergaenzend: Idealerweise Salt, Passwort und die ID o.ae. des Benutzers, damit die Gleichheit der Passwoerter verschiedener Benutzer nicht am Hash-Wert erkennbar ist.
Äh, schrieb ich nicht exakt in dem zitierten Teil, man solle eine "one way hash function" mit einem Salt benutzen?
Ja. Was Du nicht schriebst, ist die ID.
Wer lesen kann, ist klar im Vorteil!
Richtig. ;-)
»» Im Uebrigen halte ich den Begriff "Zufallswert" fuer einen Hash fuer arg irrefuehrend.
Wo soll ich denn so einen Unsinn geschrieben haben?
Hier habe ich den Unsinn geschrieben - <del>Hash</del><ins>Salt</ins> - es bezog sich alles auf den Salt.
Also nochmal: Der mir gelaufige Umgang mit Salts ist marginal anders als der von Dir und Sven. Ein Salt fuer alle, daher wird Salt, Passwort UND ID in den Hash gesteckt.
Vorteil: Effizienter im Speicher, weil - genau - keine individuellen Salts gespeichert werden muessen. Und die ID verhindert
Das ist falsch. Konstante Salt-Werte machen aus identischen Passwörtern identische Hash-Werte.
das.
Nachteil: Ggf. niedrigere Sicherheit bei vielen Datensaetzen, wie Sven schrieb:
Arbeitet man mit statischen Salt-Werten, würde es sich sonst eventuell irgendwann lohnen, für eine große Menge an Passworthashes wieder Rainbowtables zu rechnen.
"Ggf." deshalb, weil der Salt natuerlich i.a. nicht in der Datenbank steht - wer nur Zugriff auf die Datenbank und damit die Hashwerte hat, kennt also deshalb noch nicht den Salt.
Ich wollte es auch nicht besser wissen, ich hatte wirklich missverstanden - das ging ja aus Deinem Posting nicht so klar hervor, wenn man es nicht wusste - dass Du einen zufaelligen Salt _pro_ Passwort meinst. Danke Dir und Sven jedenfalls fuer die Nachhilfe ;-)
Viele Gruesse,
der Bademeister