Benutzerdaten einer Website - weg von MD5

[Matze]

Hallo zusammen,

gerade durch die phpBB.de-Geschichte, bin ich am Überlegen, ob ich die Benutzerpasswörter der Benutzer meiner Website anders hashen soll. Momentan nutze ich, wie viele andere, den MD5-Algorithmus. Ein anderer gewöhnlicher Hashalgorithmus wie SHA1 bringt meiner Meinung nach nichts, da man mittels Bruteforce, sofern der Hashalgorithmus bekannt ist, ähnlich viel erreichen kann, wie bei einem HD5-Hash.

Nun wurde im entsprechenden Thema das Salting angesprochen. Diesbezüglich bin ich auf php.net auf die crypt-Funktion gestoßen.
Das Problem ist, ich möchte nicht unbedingt jeden registrierten Benutzer auffordern, ein neues Passwort einzugeben. Das wirkt sonst so, als sei die Datenbank geknackt worden, was ich vertuschen möchte und man müsse deshalb die Daten ändern (das würde ich vermutlich als erstes denken).

Wahrscheinlich komme ich ohne weiteres jedoch nicht drum herum:

Zitat von alcaeus:

Sobald die Passwoerter erstmal gespeichert sind, bringt nachtraegliches Salten nichts mehr; es sei denn du hashst das bereits gehashte Passwort nochmal mit Salt, was aber wiederum die permanente Anwesenheit von Update-Code erfordert bis jedes Mitglied sein Passwort neu eingegeben hat.

Da das phpBB die Passwörter als MD5-Hash abspeichert und das vBulletin dies anders machen müsste, würde es heißen, dass bei einer Forenumstellung jeder sein Passwort neu eingeben muss und das ist definitiv nicht der Fall. Daher denke ich, dass es irgendwie schon möglich sein müsste, das Passwort beizubehalten bzw. dessen Hash umzurechnen.

Wie funktioniert das und was würdet ihr mir empfehlen?

Grüße, Matze

[sakura]

Die einzige Möglichkeit, welche ich sehe, ist den MD5 des Passworts mit einem Salt nochmals zu Hashen. Ob das wirklich besser ist, das wage ich zu bezweifeln.

Ansonsten kannst Du es nur über diesen "ewigen Updatecode" machen. Den zu nutzen ist imo aber auch nicht schlimm. Das kann transparent im Hintergrund geschehen, so dass die Nutzer nichts mitbekommen. Zusätzlich zum Salt-String, welcher in der DB steht, würde ich einen weiteren Salt nutzen, der fest im Code steht. Das macht es für den Nichts-Ahnenden Angreifer nochmals schwieriger das Passwort via Brute-Force zu finden.

......

[Matze]

Hallo Daniel,

sowohl das Updateskript als das doppelte Hashen gefallen mir eigentlich nicht so sehr. Wobei das Updateskript wäre noch ok, da müsste ich mich mal schlau machen, wie das funktioniert.
Meinst du, ich habe einen Salt-String in der Datenbank, der zum Hashen mitverwendet wird? Denn das kommt mir nicht sehr sicher vor, da ein Angreifer diesen "Schlüssel" zusammen mit den Daten erhält und evtl. damit an die Benutzerdaten kommt. Natürlich konnte ich den Salt-String auch in eine PHP-Datei packen, dann wäre das gelöst.
Persönlich kommt mir es sicherer vor, wenn man einen zufälligen Salt-String nutzt, damit auch der Hash identischer Passwörter unterschiedlich aussieht. Nur müssten diese Strings dann auch irgendwo abgespeichert werden und in der Benutzerdaten-Tabelle wäre das Fehl am Platz.

Grüße

[Khabarakh]

Zitat von Matze:

Nur müssten diese Strings dann auch irgendwo abgespeichert werden und in der Benutzerdaten-Tabelle wäre das Fehl am Platz.

ASP.Net macht es jedenfalls so. Ob das nun heißt, dass die Microsoftler wohl wissen werden, was sie tun, oder genau das Gegenteil *g*, das kann ich nicht beantworten. Aber auch wenn der Salt bekannt ist, verhindert er doch den Angriffstyp Nr.1: Rainbow Tables.
Wichtig für einen guten Salt ist dadurch imo nur eine angemessene Länge (ASP.Net: 10 Byte), volle Ausnutzung des Zeichensatzes und Per-User-Vergabe.

[Chewie]

Sicherheitstechnisch sollte auch das doppelte Hashen einen Gewinn bringen. Denn dadurch hättest du die direkten Hashwerte der Passwörter auch nicht mehr vorliegen und verhinderst dadurch Attacken durch Rainbow-Tables. Als Nachteil bringt diese Variante zwar den erhöhten Rechenaufwand für die Verifikation, da zweimal gehahst werden muss, aber das sollte normalerweise zu vernachlässigen sein.

Aber die größte Sicherheitslücke ist immer noch die Übertragung selbst - wenn die Passwörter im Klartext durch die Leitung gehen, kann jemand da angreifen und sich nicht mühsam in die Datenbank einhacken.

[Matze]

Das doppelte Hashen (Bsp MD5 und SHA1) hätte den Vorteil, dass ich den bestehenden Hash einfach erneut hashen kann und so die Passwörter erhalten bleiben. Doch ich denke, da kann man auch recht leicht dahinterkommen. Vielleicht lässt sich das sogar am Hashwert erkennen.

Bei der Übertragung gebe ich dir recht, doch in Blogs (und Foren) ist das leider nicht häufig anzutreffen, zumindets kenne ich keinen, bei dem dies so wäre. Ich muss zugeben, dass ich mich mit SSL (https) noch nicht auseinandergesetzt habe und auch nicht weiß, ob mein Server dies unterstützt. Ich kann mir auch nicht vorstellen, dass jemand versucht, so die Passwörter von benutzern meiner kleinen Website herauszufinden, aber schön wäre so eine Lösung.

[cware]

genau aus dem grund schreibt man sich für den datenbank-zugriff IMMER ein zusätzliches modul, dass die ganzen sicherheits-vorkehrungen automatisch trifft... sobald so'n ding da ist, kann man es mit code-injection bombardieren, bis einem schlecht wird...
die aussage, dass es keine sicherheitslücke in phpBB ist schlichtweg gelogen...
dass ist so, als ob ich einen FTP-server schreibe, einen debug-zugang ohne passwort fest einkompiliere und dann sage, dass derjenige sich ja nicht eingehackt hat... stimmt... er hat den leichten weg genommen...

zu dem bruteforcing:
wenn man das bruteforcing erschweren will, sollte man versuchen, die Anzahl der Elemente des Definitionsbereichs zu erhöhen...
oder anders ausgedrückt: man sollte versuchen, vor dem hashen statt einem ascii-text einen binärtext zu erhalten...
auch der salt sollte möglichst binär sein...
das erste, was man versucht, ist, den Definitionsbereich zu verringern... die verkleinung des Definitionsbereich verringert nämlich die Komplexität in abhängigkeit von der länge des ausgangstextes...

*ehem*
angenommen, wir sind im unären Zahlensystem (wobei 1 zur Basis 1 = 0 zur Basis 10, oder einfach ausgedrückt 0 = 1, 1 = 11, 2 = 111, etc.)...
dann müssen wir für jede stelle genau ein Element prüfen... die Komplexität liegt also bei n...
(um ein Wort der maximal-Länge n zu bruteforcen, müssen wir genau n worte testen [naja, eigentlich n-1, aber wen stört's])...
im binären Zahlensystem müssten wir bei n Stellen bereits 2^n Zustände prüfen, im ternären system 3^n etc. pp.

um es mal an zahlen auszumachen...
angenommen, wir lassen nur passwörter mit mind. 8 zeichen zu...
wenn wir unsere passwörter in binärform hashen (8bit definitionsbereich), haben wir 18446744073709551616 mögliche wörter...
wenn wir nur passwörter mit groß- und klein-buchstaben, zahlen und ein paar sonderzeichen zulassen, kommen wir auf einen definitionsbereich mit etwa. 72 elementen (bei vielen systemen sind es weniger) und somit auf 722204136308736...
die anzahl der zu testenden passwörter ver-25.000-facht sich...

mit einem binären salt vergrößert sich diese zahl natürlich noch...


cheers...

P.S.: was man natürlich beachten muss, sind evtl. vorhandene kolisionen... diese sind allerdings nicht vermeidbar, da hashing ja immer eine surjektive abbildung ist...

[franktron]

Also bei unseren Servern wird nachdem 5 misslungenen Versuch die IP auf eine Banlist geschrieben womit die Firewall die IP 24 Std. Blockt.

Na dann viel Spass beim Bruteforce man sieht sich in ca. 10 Jahren wieder

[Matze]

Ähm hab ich richtig verstanden, der lange Text soll mir lediglich mitteilen, ich soll ein Passwort vor dem Hashen in eine Binärform bringen.

[cware]

den text in eine binärform bringen unter der premisse, dass die länge des wortes gleich lang bleibt, ja... das kann zum beispiel durch das einrechnen von stördaten/varianzen geschehen, durch die dann theoretisch alle 256 zustände in einem ungehashten wort vorkommen können...
das schöne: selbst, wenn der algorithmus für das einrechnen der varianzen bekannt ist, bringt das nichts, weil wir ja einwegfunktionen benutzen...
sprich: md5(vary(Wort)) != vary(md5(Wort))
oder anders: die Varianz kann nicht vor dem Bruteforcen herausgerechnet werden...


cheers...

P.S.: wegen dem langen text - da hatte ich grad Mathe-Vorlesung... hat wohl abgefärbt...