md5 und salts

Aloha. Wusst nich genau, wohin, also hab ichs nu mal hier reingestellt, da ichs für ne weibseite nutzen will

Und zwar geht es um eine verschlüsselung von Passwörtern in einer Datenbank.

Da ich mich nicht ausschliesslich auf md5s verlassen will, habe ich vor mit einem salt zu arbeiten.

Da ich eigentlich keine lust habe zu jedem user einen eigenen salt zu speichern, oder einen systemweiten festen salt zu verwenden habe ich mir gedanken um einen variablen salt gemacht.

Wäre nett, wenn ihr euch dazu äussern könntet, ob soetwas Sinn macht (Womit ich nicht meine, ob ihr es für Sinnvoll haltet, die Sicherheit zu erhöhen) und so überhaupt einen Effekt erzielt, wie er sicher sein sollte.

Meine Idee ist folgende:
erstelle einen normalen md5 hash vom passwort
man nehme den hash und XOR'e ihn mit dem passwort (halt nur soviele stellen, wie das PW auch hat) und verwende dieses als Salt für die generierung des eintrags in der Datenbank.

Dadurch hätte ich einen salt, der variabel gehalten ist.
Vorteil: Auch, wenn 2 verschiedene strings den selben md5 wert hervorbringen (womit man ja auch theoretisch mit einem anderen string den selben hash wert wie pw+(konstantem salt) haben kann), erzeugen sie dennoch einen anderen salt (zumindest sehr ahrscheinlich).
Ausserdem: selbst wenn jemand an die DB Daten kommt und die hash haben sollte: ein Angriff über Rainbowtabellen sollte trotzdem nicht möglich sein. (Was einer der Hauptgründe für das "hohe maß" an sicherheit ist)

Somit müsste das ganze doch noch eine Stufe sicherer sein.
Oder hab ich da nen denkfehler drin?

Falls es ejmanden Interresiert: Hintergrund ist folgender: Das ganze soll eine kleine miniaccountverwaltung für die Praktikumsanmeldung einer Vorlesung der FH sein. Da diese Seite - sofern sie am ende gut wird - dann wohl auch über einen längeren Zeitraum benutzt würde, würden wohl auch ein haufen an Hilfsstudenten an die Datenbank kommen. Und je mehr Leute im laufe der zeit zugriff haben, desto höher die wahrscheinlichkeit, das mal eienr mit bösen absichten dahin kommt.

Vielen dank im voraus und nen schönen Gruß,
o_O

Hallo,

offen gestanden, das wäre mir viel zu viel Aufwand.
Was spricht denn gegen sha512 oder z.B. Whirlpool? Da ist es zum jetzigen Zeitpunkt und auch in absehbarer Zukunft mit Rainbow Tables ziemlich düster, und du hast absolut keinen Mehraufwand, außer vielleicht, schnell das mcrypt-Plugin für PHP zu aktivieren.

MD5 hat schon lange ausgediehnt ...

Shade Of Mine

@árn[y]ék:
egal welchen hash algo du verwendest, du musst salts verwenden.

@o_O:
Wozu so kompliziert? Du koenntest zB das passwort selbst als salt verwenden:
zB 10mal md5 auf das passwort ist der salt.

Zu kompliziert denken ist in solchen Sachen meistens schlecht. Simple, einfache Loesungen sind besser, da man so die Schwachstellen nicht aus dem Auge verliert.

Shade Of Mine schrieb:

Wozu so kompliziert? Du koenntest zB das passwort selbst als salt verwenden:
zB 10mal md5 auf das passwort ist der salt.

naja, wenn aber trotz versalzen ein passwort immer die selbe bitfolge generiert ist das nicht besonders sinnvoll. lieber echte zufallswerte nehmen.

Ganz echte zufallswerte sind ja auch irgendwie doof. Weil die müssen ja auch wieder mitgespeichert werden.

Sha512 bzw Whirpool muss ich mal schaun. vielleicht reicht das ja auch. Danke für den Hinweis

Andererseits:
Aufwand? So wirklich groß is der Aufwand ja net.

$pw = $_POST["pw"];

$preHash = md5($pw);

$salt = $preHash xor $pw;

$encryptedPW = md5( $salt . $pw);

Das wars im prinzip ja schon.

nachtrag: ganz vergessen: strings xor'en is in php ja was umständlicher. aber dennoch machbar.^^"

Christoph

o_O schrieb:

Ganz echte zufallswerte sind ja auch irgendwie doof. Weil die müssen ja auch wieder mitgespeichert werden.

Sha512 bzw Whirpool muss ich mal schaun. vielleicht reicht das ja auch. Danke für den Hinweis

Andererseits:
Aufwand? So wirklich groß is der Aufwand ja net.
$pw = $_POST["pw"];

$preHash = md5($pw);

$salt = $preHash xor $pw;

$encryptedPW = md5( $salt . $pw);
Das wars im prinzip ja schon.

Das ist aber kein Salt. Der Sinn und Zweck eines Salts ist, rainbow-tables zu erschweren. Das funktioniert aber nur, wenn zwei gleiche Passwörter nicht auf den gleichen Hash abgebildet werden.

Wenn das Salt aus dem Passwort selbst erzeugt wird ohne Zufallsdaten hinzuzufügen, kann man es auch gleich sein lassen.

Denn du hast effektiv nur einen anderen Hash-Algorithmus implementiert: Du berechnest md5(f(passwort)) anstatt md5(passwort), wobei f deine "prehash-xor"-Funktion ist. Der Sicherheitsgewinn ist nahe null, denn auch bei Hash-Algorithmen sollte Kerckhoffs Prinzip gelten: Der Algorithmus darf bekannt werden, ohne die Sicherheit zu gefährden.

Hallo,

ich hatte die Frage falsch verstanden ... War gerade aufgestanden

SHA512 oder Whirlpool sind einfach neuere, sicherere Hashalgorithmen. Der Salt soll ja den Einsatz von Rainbow-Tables erschweren bzw. dafür sorgen, dass su aus gleichen Hashes in der Datenbank nicht mehr auf gleiche Ausgangspasswörter Rückschlüsse ziehen kannst. In dem Sinne sind sie auf jeden Fall erforderlich. Ich benutze bei meiner Software einen Zufalls-Hash (mt_rand()) + Whirlpool, wobei die Zukunft noch zeigen wird, ob Whirlpool wirklich so sicher ist. Momentan sind die Untersuchungen da noch recht rar.

@Shade
Welchen Sinn macht es denn, den Salt aus dem Passwort selbst zu berechnen? Damit hat man ja wieder einen der Vorteile - eben unterschiedliche Hash-Werte in der DB bei gleichem Ausgangspasswort - verworfen.

EDIT: Gerade erst Christophs Beitrag gelesen ... Genau das meinte ich.

Shade Of Mine

árn[y]ék schrieb:

Welchen Sinn macht es denn, den Salt aus dem Passwort selbst zu berechnen? Damit hat man ja wieder einen der Vorteile - eben unterschiedliche Hash-Werte in der DB bei gleichem Ausgangspasswort - verworfen.

Es ist nicht ideal und idR nimmt man ja deshalb noch user daten mit rein, zB die ID. aber worum es geht ist sich gegen standard rainbow tables zu schützen.

natürlich ist es besser wenn man pro user eine rainbow table braucht als eine für alle - aber das essentielle ist ja, dass man gegen vanilla rainbow tables sicher ist.

Christoph

Shade Of Mine schrieb:

árn[y]ék schrieb:

Welchen Sinn macht es denn, den Salt aus dem Passwort selbst zu berechnen? Damit hat man ja wieder einen der Vorteile - eben unterschiedliche Hash-Werte in der DB bei gleichem Ausgangspasswort - verworfen.

Es ist nicht ideal und idR nimmt man ja deshalb noch user daten mit rein, zB die ID. aber worum es geht ist sich gegen standard rainbow tables zu schützen.

natürlich ist es besser wenn man pro user eine rainbow table braucht als eine für alle - aber das essentielle ist ja, dass man gegen vanilla rainbow tables sicher ist.

Eine rainbow table kann man sich selbst berechnen, sobald man den Hash-Algorithmus kennt (der Hash-Algorithmus ist dann halt nicht "md5(passwort)", sondern eben "md5(f(passwort))"). Nur ein richtiges Salt erschwert das.

IMHO gibt so ein "Pseudo-Salt" nur trügerische Sicherheit und kann damit gefährlicher sein als gar kein "Pseudo-Salt".

edit: Wie du gerade gesagt hast, ist es auch kein großer Aufwand ein richtiges salt zu verwenden.

Shade Of Mine

Christoph schrieb:

[Eine rainbow table kann man sich selbst berechnen, sobald man den Hash-Algorithmus kennt (der Hash-Algorithmus ist dann halt nicht "md5(passwort)", sondern eben "md5(f(passwort))"). Nur ein richtiges Salt erschwert das.

IMHO gibt so ein "Pseudo-Salt" nur trügerische Sicherheit und kann damit gefährlicher sein als gar kein "Pseudo-Salt".

Es schützt vor standard angriffen - und das ist wovor man angst haben muss. wenn ich eine eigene rainbow table pro angegriffene seite erstellen muss - dann lohnt sich der aufwand fast nicht. wenn ich es pro user erstellen muss, lohnt er sich überhaupt nicht.

natürlich ist überhaupt nicht besser als fast nicht - aber die wirkliche gefahr geht von vorberechneten rainbow tables aus, nicht von speziell generierten.

manchmal ist es so, dass man keine anderen daten als das "passwort" hat - dann ist ein 10maliges md5 des "passworts" ganz gut geeignet. da du dadurch die kosten zur generierung der rainbow table ziemlich in die höhe treibst.

wenn natürlich möglich ist es besser user spezifische daten als salt zu nehmen. aber das essentielle ist, gegen die standard rainbow tables gesichert zu sein. denn eine fertige tabelle irgendwo hernehmen und dann gegen die gestohlenen daten laufen lassen ist trivial. selber eine rainbow table berechnen dagegen nicht.

worum es im prinzip geht ist standard verfahren abzuschiessen. wenn jemand wirklich will, knackt er sowieso alles. deshalb ist der 1. schritt dass man alle automatisierten standard tools blocken kann. der angreifer muss gezwungen werden meine daten speziell und händisch zu bearbeiten. das ist die große hürde ab der sich die kosten/nutzen-rechnung nicht mehr lohnt.

alles was danach kommt ist bonus (natürlich in diesem fall hier bonus der ohne mehraufwand daherkommt und deshalb mitgenommen werden sollte).

volkard

viel besser ist, h(pwd)=md5(pwd)+sha1(pwd)+whirlpool(pwd) zu speichern, würde ich meinen.
wenn dann mal md5 gerainbowt ist, halten die beiden anderen trotzdem dicht.
falls überraschend ein anderer auch noch einknickt, was solls? dann nimmste wieder drei gutriechende hashverfahren, an die du rankommst.

und immer viel angst haben, wenn man so verfahren nachträglich pimpt!!! erinnert eich an die enigma, wo das prima ergebnis nach drei stufen wieder zurückgespiegelt und nochmal durchgeleitet wurde und sie erst durch diesen pimpup knackbar wurde, eine kryptographische kathastrophe!
es kann sein, daß md5^10 viel schwächer als md5 ist. also bitte nicht selber dran schrauben. nur gut füttern.

und für
s=zufall()+"projektname"
h(pwd)=s+md5(s+pwd)+sha1(s+pwd)+whirlpool(s+pwd)
kriegste bestimmt einen webmaster-paranoia-preis.

Shade Of Mine

volkard schrieb:

es kann sein, daß md5^10 viel schwächer als md5 ist

Mag sein, aber das wäre in diesem Fall egal - da der hash ja nur salt ist. das x-malige md5 erhöht lediglich den aufwand den hash zu berechnen.

und für
s=zufall()+"projektname"
h(pwd)=s+md5(s+pwd)+sha1(s+pwd)+whirlpool(s+pwd)
kriegste bestimmt einen webmaster-paranoia-preis.

Das ganze steht und fällt doch mit dem salt.
Egal wie aufwendig du den Hash berechnest, solange die eingabedaten konstant sind, kannst du es rainbowen.

Die Idee ist nun, dass du für jeden User einen eigenen Salt verwendest. Dadurch musst du pro user eine eigene rainbow table bauen und das ist ein enormer rechen aufwand. welchen hash algo man dann verwendet ist im prinzip egal.

den salt oft hashen bringt dabei eben zusätzlich noch längeren aufwand für den angreifer. denn ob er 1 mal hashen muss oder 11 mal, ist für die login anwendung egal - aber wenn du statt N*hash plötzlich N*hash*11 hast, dann steigt die komplexität recht rasch an

volkard

Shade Of Mine schrieb:

Die Idee ist nun, dass du für jeden User einen eigenen Salt verwendest. Dadurch musst du pro user eine eigene rainbow table bauen

äh, nein. wenn das salt nur f(pwd) ist, dann geht ja doch wieder eine rainbow-table für alle user. es ist wieder nur eine abbildung von passwort auf hash.
und sie ist nicht so tausendfach getestet wie simples md5 und unvertrauenswürdiger.
die hauptgefahr der rainbow-cd ist gebannt, ok.
aber wir haben noch die rainbow-table gegen die ganze datenbank statt gegen nur einen nutzer.
und da wirste ohne den onkel zufall oder benitzerID nicht wirklich was erreichen können.

Shade Of Mine

volkard schrieb:

äh, nein. wenn das salt nur f(pwd) ist, dann geht ja doch wieder eine rainbow-table für alle user.

Deshalb nimmt man dann ja zB die User ID oder den User Namen oder das eintrittdatum, etc. Egal was - solange es sich nicht ändert.

volkard

Shade Of Mine schrieb:

vanilla rainbow tables

das wort ist einfach hübsch.
es sind, wie ich eine freundin gerade befragt habe, vanille-regenbogen-tafeln, vielleicht ein rezept für plätzchen.
(ob ich ihr sagen sollte, daß wir schon 2 seiten lang diskutieren, welches salz man reintun soll?)