4. Warum Passwörter in der Datenbank mit md5 "verschlüsseln"?

Warum Passwörter in der Datenbank mit md5 "verschlüsseln"?

  • ?

    Admins und Mods sind ja auch keine heiligen Zauberwesen.

    0
  • R

    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 ...

    0
  • ?

    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.

    0
  • ?

    Mit "hosten" ist gemeint, auf meinem Rechner läuft die Forensoftware.

    0
  • M

    Deswegen muss man die Passwörter dennoch nicht auf dem Silbertablett präsentieren.

    0
  • ?

    Ich sag nur, dass man den Hoster nicht hindern kann. Natürlich gehören Passwörter trotzdem gehashed.

    0
  • M

    Bezweifelt ja auch keiner. Trotzdem gehören Passwörter nicht auf dem Silbertablett präsentiert. Moment mal, ich glaub das hab ich schon gesagt 😃

    0
  • ?

    md5 würde ich gar nicht für passwörter verwenden, der ist nicht sicher 👎

    0
  • N

    der benutzer hackt sein passwort sowieso im klartext rein. besser wär vielliecht wenn es schon vor der übertragung verschlüsselt würde

    0
  • R

    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 ...

    0
  • ?

    Was bringt es dir denn, das gehashte Passwort zu kennen?

    0
  • R

    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.

    0
  • M

    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.

    0
  • N

    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.

    0
  • N

    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.

    0
  • ?

    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. 😉

    0
  • L

    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.

    0
  • B

    einfach md5*multiplikator und dann hilft da nichts mehr^^

    0
  • S

    Es ist doch egal, wie die Passwörter gespeichert werden, der Admin kommt immer dran... (beim Einloggen wird das PW unverschlüsselt übertragen, d.h. wenn er die Software umschreibt und das PW sich z.B. per Email zusenden lässt, beim Einloggen; und das dann noch filtert, ob es stimmt, dass er natürlich keine falschen erhält, hat er sie doch...🙄

    0
  • R

    Richtig. Vor dem Systemadministrator versucht man sie i.d.R. aber auch nicht zu verbergen. Und nach wie vor gilt: Einmal gehashte Passworter kriegt keiner im Klartext! (naja, zumindest nicht ohne Weiteres 😉 )

    0
Anmelden zum Antworten