Warum Passwörter in der Datenbank mit md5 "verschlüsseln"?
-
Ganz einfach der, dass auch andere, z.B. der Serveradministrator, andernfalls Passwörter sehen könnte, die ihn schlichtweg nichts angehen.
Außerdem -> Einen Server cracken ist eine Sache, Identitätendiebstahl eine ganz andere! Und gerade die nimmst du grob fahrlässig in Kauf, wenn du die Passwörter deiner User nicht verschlüsselst. Rufschädigung sei da auch mal genannt.
Im übrigen ist md5 gar nicht sooo etabliert: Ich kenne viele Projekte, die auf sha1 (shaX) bauen!
-
Reyx schrieb:
Ganz einfach der, dass auch andere, z.B. der Serveradministrator, andernfalls Passwörter sehen könnte, die ihn schlichtweg nichts angehen.
der admin kann sich jederzeit die passwörter holen, indem er die software umfrickelt.
-
Admins und Mods sind ja auch keine heiligen Zauberwesen.
-
volkard schrieb:
der admin kann sich jederzeit die passwörter holen, indem er die software umfrickelt.
Durchaus, aber nur diejenigen, die noch nicht mit einem Hash-Algorithmus gespeichert wurden. Was ich mit "Systemadministrator" meinte ist z.B., wenn man eine seiten bei einem ISP hosten lässt -> Dann geht es die Admins vom ISP gar nichts an, welche Passwörter irgendwie gespeichert werden!
Das das in der Praxis oft anders gehandhabt wird, weiß ich, aber vom Prinzip her müsste das eigentlich so sein ...
-
Es ist doch egal, ob ein ISP das hostet oder ich auf meinem Pentium 400 MHz. Jeder, der das Ding hostet, kann sich das Passwort beschaffen.
-
Mit "hosten" ist gemeint, auf meinem Rechner läuft die Forensoftware.
-
Deswegen muss man die Passwörter dennoch nicht auf dem Silbertablett präsentieren.
-
Ich sag nur, dass man den Hoster nicht hindern kann. Natürlich gehören Passwörter trotzdem gehashed.
-
Bezweifelt ja auch keiner. Trotzdem gehören Passwörter nicht auf dem Silbertablett präsentiert. Moment mal, ich glaub das hab ich schon gesagt
-
md5 würde ich gar nicht für passwörter verwenden, der ist nicht sicher
-
der benutzer hackt sein passwort sowieso im klartext rein. besser wär vielliecht wenn es schon vor der übertragung verschlüsselt würde
-
Wenn das Passwort schon vor der Übertragung verschlüsselt währe, dann bräuchte man nur die Leitung anzapfen oder entsprechende Software benutzen um das Passwort abzufangen! In sofern würde es dir überhaupt nichts bringen ...
-
Was bringt es dir denn, das gehashte Passwort zu kennen?
-
Ganz einfach: Wenn es schon vor der Übertragung gehasht wird, dann wird es im Anschluss nicht noch einmal gehasht. Dass heißt, dass übertragene Passwort ist exakt dass, mit welchem sich der Benutzer einloggt.
-
Es bringt einem so viel wie das Klartext-Passwort zu kennen.
Wenn das Passwort vor der Übertragung einweg-verschlüsselt wird, kann der Server auch nicht viel mehr machen als dieses verschlüsselte Passwort mit dem abgespeichertem zu vergleichen. Das heißt, wenn ich das verschlüsselte kenne, schicke ich dem Server eben das verschlüsselte und dieser muss es notgedrungen akzeptieren ... den Klartext muss man in dem Fall überhaupt nicht kennen.
Da existiert bei dem Verfahren also absolut kein Unterschied zur Klartext-Übertragung.
-
minhen schrieb:
Da existiert bei dem Verfahren also absolut kein Unterschied zur Klartext-Übertragung.
etwas besser ist es schon. der hacker muss das format kennen bzw. die stelle im paket wo das verschlüsselte passwort kommt. aber besser man verwendet eine art challenge-response verfahren. dabei schickt der server eine zufallszahl und das passwort wird damit verschlüsselt.
-
Idealerweise verwendet man ein Challenge-Auth (wie beim Q-Bot im Quakenet, falls das einer kennt). Der Server gibt dir einen String, und du sendest dann md5(string + passwort) zum Einloggen zurück. Beim nächsten Login wäre der gleiche Hash dann ungültig, weil der String sich bei jedem Login ändert.
-
Reyx schrieb:
Ganz einfach: Wenn es schon vor der Übertragung gehasht wird, dann wird es im Anschluss nicht noch einmal gehasht. Dass heißt, dass übertragene Passwort ist exakt dass, mit welchem sich der Benutzer einloggt.
So ist das auch nicht gemeint gewesen. Das Passwort soll gehasht, wie übertragen, in die Datenbank gespeichert werden. Beim Einloggen muss man natürlich ein Klartext-Passwort an den Server senden, der hasht es und vergleicht die Hashs.
Bringt aber eigentlich nix. Ok, vergiss es. War ja auch nicht meine Idee.
-
mal ne frage:
wenn ich an die hashes der PWs in der DB rangekommen bin, könnte ich ja ne riesen rainbow-list mit werten und deren hashes bauen und so eine kollision finden, also ein PW mit dem selben hash, und so reinkommen, als hätte ich das echte PW.die simple idee wäre jetzt, nicht nur z.B. MD5 zu nutzen, sondern z.B. MD5 _und_ SHA1. ohne groß nachzudenken glaube ich, dass das die sicherheit erhöht, da man jetzt rainbow-listen (noch) absurder(er) größe bräuchte....
aber ist das wirklich sicherer, oder übersehe ich da was (und ist es am ende vielleicht sogar unsicherer?)
thanks in advance...
---loki
/EDIT: und sorry dass ich diesen thread hier wiederbelebt habe.
-
einfach md5*multiplikator und dann hilft da nichts mehr^^