Salts - aber wie?

[queicherius]

Durch das Thema bin ich auf die Frage gekommen: Jeder Benutzer hat einen eigenen Salt, also Datenbanktabelle:

--------------------------------------------------------
|id |username |password         |salt
|1  |testuser |md5-hash mit salt|salt fuer den benutzer
--------------------------------------------------------

Kann der potentielle Angreifer dann nicht das Passwort genauso einfach rausfinden wie ohne den Salt?

Angreifer:
md5(testpasswort+salt) == bekannter Hash

Oder wie speichert man das? Hat jemand ne Anregung?

 

[Mainclain]

Durch das Thema bin ich auf die Frage gekommen: Jeder Benutzer hat einen eigenen Salt, also Datenbanktabelle:

--------------------------------------------------------
|id |username |password         |salt
|1  |testuser |md5-hash mit salt|salt fuer den benutzer
--------------------------------------------------------

Kann der potentielle Angreifer dann nicht das Passwort genauso einfach rausfinden wie ohne den Salt?

Angreifer:
md5(testpasswort+salt) == bekannter Hash

Oder wie speichert man das? Hat jemand ne Anregung?

In diesem Falle ist Brute-Force-Methode natürlich dennoch möglich, allerdings kannst du das HASH-Password nicht so einfach aus einer Rainbowtabelle herausholen.
Und um das ganze noch schwerer zu machen könnte man dann ja noch ein weiteren statischen eintrag hinterhängen - klar kann auch herausgefunden werden, allerdings wäre dies wieder ein weiterer Zeitaufwand für den Angreifer.
Vor Brute-Forcing könnte man sich sicher auch anders schützen - Z.B. darf nur 10 mal kurz hintereinander ein falsches password eingegeben werden - dann wirds gesperrt und zwar nicht nur für einen Benutzer, sondern gleich für alle (also für jeden der sich in den user einloggen will).
Wenn man danach 1 Minute warten muss - Kann man sich ja vorstellen wie lange solche Angriffe brauchen würden.

 

[Sven Mintel]

Ich würds mal so sagen(Bruteforce aussen vor gelassen, denn damit spielt das alles eh keine Rolle, wie sehr du versuchst, da irgendwas zu verschlüsseln /hashen...davor schützt du dich bspw. mit der von Mainclain genannten Methode).

Die Sache mit den Hashes dient nicht der Sicherheit des Logins, sondern der Sicherheit der Daten in der DB.

Szenario: ein Angreifer gelangt an die Inhalte der DB:

Du hast md5-(oder sonstige Standard-)Hashes der Passwörter in der DB gespeichert:

der Angreifer kennt sein eigenes Passwort, und kann darüber herausfinden, welcher Natur der Hash ist...dann muss er nur noch zu den anderen Hashes die Passwörter aus der passenden Rainbow-Table fischen.

Verwendest du keinen Standard-Hash, ist es für ihn notwendig, nicht nur an die DB zu gelangen, sondern auch an die Skripte, die die Hashes anlegen/prüfen...denn nur dort kann er herausfinden, wie die in der DB hinterlegten Daten geprüft werden.
(hast du das Salt bspw. vorne oder hinten an das Passwort angehangen, hast du zusätzlich den von Mainclain erwähnten statischen Zusatz verwendet und wie sieht der aus und wo befindet er sich).

 

[queicherius]

darf nur 10 mal kurz hintereinander ein falsches password eingegeben werden - dann wirds gesperrt und zwar nicht nur für einen Benutzer, sondern gleich für alle (also für jeden der sich in den user einloggen will).
--
Und um das ganze noch schwerer zu machen könnte man dann ja noch ein weiteren statischen eintrag hinterhängen - klar kann auch herausgefunden werden, allerdings wäre dies wieder ein weiterer Zeitaufwand für den Angreifer.

Das hab ich mal kurz soweit integriert Danke für die Vorschläge!

Verwendest du keinen Standard-Hash, ist es für ihn notwendig, nicht nur an die DB zu gelangen, sondern auch an die Skripte, die die Hashes anlegen/prüfen...denn nur dort kann er herausfinden, wie die in der DB hinterlegten Daten geprüft werden.

Meinst du zum Beispiel wenn man 2 mal hasht? Das ist dann ja auch kein Standart mehr, oder?
Und sind dann Open-Source-Sachen nicht potentiell gefährdet, weil da jeder in den Code kucken kann?

 

[wod2008]

Vor Brute-Forcing könnte man sich sicher auch anders schützen - Z.B. darf nur 10 mal kurz hintereinander ein falsches password eingegeben werden - dann wirds gesperrt und zwar nicht nur für einen Benutzer, sondern gleich für alle (also für jeden der sich in den user einloggen will).

Was ein Müll, kann man dann alle accouns sperren in dem man sich 10 hintereinander pro account versucht einzuloggen?
Binde einfach nach ca 4 fehlerhaften Versuchen beim nächsten Versuch ein capatcha ein.

 

[Mainclain]

Das hab ich mal kurz soweit integriert Danke für die Vorschläge!



Meinst du zum Beispiel wenn man 2 mal hasht? Das ist dann ja auch kein Standart mehr, oder?
Und sind dann Open-Source-Sachen nicht potentiell gefährdet, weil da jeder in den Code kucken kann?

Natürlich sind Open-Source dinge mehr gefährdet als andere - schon allein weil man Sicherheitslücken direkt im Code finden kann.
Und als eigenen kannst du auch nehmen, wenn du deinen hash noch einmal veränderst, indem du eben alle A's in B's umänderst, oder ähnliches.

Zum Anderen ist soetwas eh nur denkbar wenn man gleich mehrere Sicherheitslücken im System hat - denn wer gar nicht erst an die Hash's kommt....
Absolut sicher ist das System eh erst, wenn überall darauf geachtet wird (Angefangen bei der Konfiguration des Servers bis hin zu SQL Injection etc.)
Einen absolut sicheren Schutz kann es einfah nicht geben
Würde ich so sagen

Was ein Müll, kann man dann alle accouns sperren in dem man sich 10 hintereinander pro account versucht einzuloggen?
Binde einfach nach ca 4 fehlerhaften Versuchen beim nächsten Versuch ein capatcha ein.

Gute Idee

 

[Sven Mintel]

Meinst du zum Beispiel wenn man 2 mal hasht? Das ist dann ja auch kein Standart mehr, oder?

Das ist bestimmt sicherer als 1x hashen, aber nicht viel...der geneigte Angreifer wird das auch probieren wollen.

Du brauchst halt irgendeine (ohne Skripteinblick unbekannte) Konstante(Konstante jetzt nicht nur als Wert anzusehen, halt deine fixe Methode, wie du den Wert noch mal veränderst),...je schwerer diese zu erraten ist, desto besser(2x hashen ist nicht allzuschwer zu erraten).

 

[Flex]

Das ist bestimmt sicherer als 1x hashen, aber nicht viel...der geneigte Angreifer wird das auch probieren wollen.

Du brauchst halt irgendeine (ohne Skripteinblick unbekannte) Konstante(Konstante jetzt nicht nur als Wert anzusehen, halt deine fixe Methode, wie du den Wert noch mal veränderst),...je schwerer diese zu erraten ist, desto besser(2x hashen ist nicht allzuschwer zu erraten).

Schwerer wäre z. B. nur einen Teil des erstes Hashes erneut zu hashen. Z. B. nur die 4. - 8. Stelle.