Diskussion:Salted Hash

Der Artikel ist sprachlich einer Enzyklopädie nicht angemessen. Liest sich wie ein Foren-/Usenet-Posting. Habe aber nicht die Zeit, alles zu überarbeiten; inhaltlich ist er ja ganz brauchbar. (Vorstehender nicht signierter Beitrag stammt von 134.76.3.128 (Diskussion • Beiträge) 02:45, 9. Jul 2006)

Hallo,

ich fand es inhaltlich sehr gut, insbesondere auch verständlich, Lexikon-Stil ist es aber sicher nicht. --Badenserbub 14:56, 21. Jul 2006 (CEST)

Was mir nicht ganz klar ist:

Wenn ich bei jedem Hash-Vorgang den Salt neu erstelle, wie stelle ich dann sicher, dass der Salt beim ersten verschlüsseln und beim anschließenden Vergleich gleich sind? Wenn das nicht gegeben ist, kann ja nie ein Loginvorgang erfolgreich sein.

Moin :)

Eine höhere Sicherheit wird beim Salted Hash nicht dadurch erreicht, dass der Salt geheim ist, sondern dieser wird ganz normal mit dem Hash zusammen gespeichert. Der Login-Vorgang kann also so ablaufen, dass zu einem Benutzernamen der Salt und der SaltedHash aus der Datenbank geholt werden, das eingegebene Password mit dem Salt gehasht wird und anschließend verglichen. Der Vorteil besteht einfach darin, dass sollte, aus welchen Gründen auch immer, einmal eine Liste mit den Hashes in falsche Hände geraten, eine (Bruteforce-)Attacke mit Wörterbüchern oder Rainbowtables keinen Erfolg hat. Diese Verfahren basieren ja darauf, dass bereits viele vorberechnete Hashes vorliegen - mit dem SaltedHash müsste aber für jedes mögliche Passwort ein SaltedHash mit dem dazugehörigen Salt berechnet werden, was die ganze Sache ziemlich aufwendig bis fast unmöglich macht. --Pocmo 16:57, 24. Okt. 2006 (CEST)

Entspricht das dann nicht einem um die Größe des Salt längeren Passwort? Man kann dann ja auch zu jeder Kombination aus Passwort und Hash schöne Tabellen berechnen - sind die dann nicht gleich groß, als wäre gleich ein alternatives Passwort der Länge altes Passwort + Länge Hash benutzt worden? --87.174.12.79 21:01, 26. Dez. 2007 (CET)

soweit ich dass sehe hast du wohl recht. Dennoch bringt es enorma vorteile: man stelle sich einen User A vor der das Passwort "Baum" wählt, mit Salt "Baum4". Dieses wird geknackt und in eine Rainbow-Table aufgenommen. User B benutzt ebenfalls Wort "Baum", mit Salt "Baum7". Man kann erkennen dass das Passwort von User B nicht über die Rainbowtable geknackt werden kann. Also erschwert Salting die benutzung solcher Tables. --85.177.190.24 02:54, 7. Jul. 2008 (CEST)

d.h. in einer benutzerdatenbanken gibt es dann eine spalte user, hash, salt? wobei das Salt im klartext gespeichert wird? -- Qopep 10:06, 30. Nov. 2007 (CET)

bei übertragungsprotokollen wie TLS ist es afaik so, dass der hash bereits auf client seite berechnet wird, so dass selbst der server das klartext passwort nicht kennt. der server müsste dann aber zuerst das Salt an den client übermitteln, damit der richtige hash berechnet werden kann. sehe ich das richtig? -- Qopep 10:06, 30. Nov. 2007 (CET)

Man kann auch dies umgehen, indem man nicht hash(passwort + salt) nimmt, sondern hash(hash(passwort) + salt) berechnet. Somit muss dann nur auf Clientseite der "einfache" Hash berechnet und übermittelt werden. -- 89.182.157.133 09:41, 24. Mai 2009 (CEST)

Bei der Übertragung von Hashes über das Netz zur Authentfizierung möchte man vermeiden, dass ein statischer Wert übermittelt wird - egal ob mit oder ohne SALT. Wenn das Dritte mitlesen, haben sie sonst sowieso schon alles was sie für die Anmeldung brauchen; statt eines "statischen" SALTS wird daher eine "challenge" verwendet, die sich bei jedem Anmeldeversuch ändert (bzw. ändern sollte). --92.74.200.96 19:25, 26. Okt. 2009 (CET)