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

sma · Mittwoch 28. Juli 2010, 10:40

Mir ging es nicht darum, dass es ohne "Salz" schneller geht, sondern das es mit Salz nicht schwerer ist als ohne. Brute Force ist auf heutigen Rechnern schon verdammt schnell und ein einfacher MD5 ist damit ungenügend, um ein Kennwort zu schützen, egal ob mit oder ohne Salz.

Stefan

Darii · Mittwoch 28. Juli 2010, 10:44

Da hilft nur, das Salz zu verstreuen. Dann muss das vor Verwendung zusammengefegt werden.

Defnull · Mittwoch 28. Juli 2010, 13:57

Ein Salt soll Rainbow-Table Angriffe (Komprimierte Tabellen bekannter Klartext<->md5 Paare) verhindern. Gegen BruteForce hilft ein (öffentlicher) Salt natürlich nicht. Ist der Salt allerdings unbekannt (Hacker bekommt Zugriff auf die DB, aber nicht auf die Scripte) ist er auch da ein großer Vorteil.

BruteForce funktioniert wiederum nur bei schwachen Passwörtern. Wenn du 380.000 Passwörter pro Sekunde schaffst, sind das bei einem 8 stelligen Passwort mit Buchstaben, Zahlen und Sonderzeichen schon etwa 60 Jahre. Selbst auf Grafikkarten dauert das etwas.

sma · Mittwoch 28. Juli 2010, 22:19

Defnull hat geschrieben:etwa 60 Jahre.

Also ich kam auf 3000 Tage (bei 8 CPUs). Das sind etwas über 8 Jahre. Allerdings bin ich mir sicher, dass es bei spezieller Hardware deutlich schneller geht. Zudem kommt, dass im Schnitt ja nicht alle sondern nur die Hälfte aller Kombinationen probiert werden müssen.

Bei Amazon kann ich schon heute einen Rechner mit 8 virtuellen Kernen anmieten, die vielleicht doppelt so schnell sind, wie mein PC. Schon bin ich bei 2 Jahren oder 750 Tagen. Mit 75 dieser Maschinen dauert es dann 10 Tage und kostet etwa $12240. Hm... noch ein bisschen teuer für ein Kennwort

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

Stefan

mkesper · Donnerstag 29. Juli 2010, 09:45

Das ist alles für umsonst, wenn die Passwörter vom Benutzer eingegeben und nicht auf Sicherheit geprüft werden:
http://www.zdnet.de/news/wirtschaft_sic ... 6495-1.htm

Barabbas · Donnerstag 29. Juli 2010, 10:05

sma hat geschrieben:
Defnull hat geschrieben: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 · Donnerstag 29. Juli 2010, 10:10

sma hat geschrieben: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 · Donnerstag 29. Juli 2010, 10:34

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

Defnull · Donnerstag 29. Juli 2010, 11:12

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.