hashlib.new(string), Welche Hashfuncs gibts noch???

[Barabbas]

etwa 60 Jahre.

Das Salt zu verstecken, es also zu einem shared secret zu machen, ist kein gutes Sicherheitskonzept, da es einfach nur "security by obscurity" ist.

Naja, Defnull zielte nach meinem Empfinden nicht darauf ab, etwas zu verstecken, sondern die Sicherheit bzw. die neuralgischen Punkte auf zwei Systeme zu verteilen anstatt nach dem Motto zu verfahren "Haste dies, haste alles". So gesehen wäre das nicht "security by obscurity" und auch nicht wirklich ein "shared secret" (die DB kennt das Salt ja nicht), sondern eher ein "mehrstufiges Sicherheitsdesign" - oder habe ich euch falsch verstanden?

Schönen Gruß,

brb

[Darii]

Das Salt zu verstecken, es also zu einem shared secret zu machen, ist kein gutes Sicherheitskonzept, da es einfach nur "security by obscurity" ist.

Wenn du so willst, sind Passwörter auch nur „security by obscurity“ (und hashes sowieso). Wenn man das Salz verstreut macht man bestimmte Angriffsvektoren einfach unbrauchbar. Wird der DB-Server geknackt nützt das nichts, wenn in den Zeilen jeweils nur ein bisschen Salz ist, knackt man beide Server muss man trotzdem noch jede Zeile einzeln knacken. Zusätzliches Verschleiern von Informationen schadet nicht, so lange der Aufwand den Nutzen nicht übersteigt.

Genauso ist das auch mit dem Salz grundsätzlich. Es schützt nicht vor dem Knacken eines einzelnen Passworts. Es schützt aber davor, dass die komplette Nutzerdatenbank innerhalb kürzester Zeit geknackt wird und die so gewonnenen Passwörter zum Schaden der Nutzer verwendet werden können, weil das nicht wirtschaftlich wäre (die $10000 pro Passwort muss man erstmal wieder reinbekommen, bei nem decicent/Passwort sieht das schon anders aus).

Wenn man sicher gehen will, sollte man die Authentifizierung auf einen extra Server verlagern, der gesondert abgesichert ist. Und wo dann auch bitte nur der LDAP/Kerberos-Dienst o.Ä. drauf läuft.

[DasIch]

Man kann immernoch einfach OpenID, Facebook Connect oder OAuth über Twitter nutzen um User zu identifizieren, dann entsteht die Problematik gar nicht erst.

[Defnull]

Generell gilt: Absolute Sicherheit gibt es nicht. Der Trick ist, entweder den Aufwand zu erhöhen oder den Nutzen zu verringern, damit sich die Sache für den Angreifer nicht mehr lohnt und er sich einfachere Ziele sucht. Salz ist ein sehr einfaches Mittel, das nichts kostet und den Aufwand für den Angreifer enorm erhöht. Er kann keine Rainbow-Tables mehr nutzen und muss für die Rekonstruktion nicht nur die DB knacken, sondern auch die serverseitigen Scripte auslesen. Er braucht damit schon zwei Sicherheitslücken, um an Paydata zu kommen. Die andere Seite ist aber auch wichtig: So wenig Daten wie irgend möglich überhaupt speichern.

Was sichere Passwörter an geht: Ich persönlich finde den Ansatz, ganze Sätze als Passwort zu verwenden, sehr interessant. Passwörter wie "Mein gmail account ist sicher!" sind sehr leicht zu merken, schnell zu tippen, können je nach Dienst unterschiedlich sein und sind viel zu lang für stupides BruteForce. Selbst ein BruteForce, das Wörter statt Buchstaben benutzt, kommt damit nicht klar. Einerseits durch die unbekannte Position und Art der Sonderzeichen (Ich kann ja auch Kommata einbauen) und andererseits durch die enorme Vielfalt an Möglichkeiten pro Wort (50.000 statt 36). Nur als Beispiel: 5 Wörter aus einem 50.000 Wörterbuch bilden 3.1e23 Kombinationen. Ein 8 stelliges Passwort hat nur 2.8e12. Technisch ist das kein Ding. In der DB werden eh nur hashes gespeichert, die immer gleich lang sind, ganz egal wie lang das echte Passwort aus fällt.