md5 und salts

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?)