Salt-Wert

Hi,

ich habe eine Frage zum Salt-Wert bei Verschlüsselungen. Wenn man ein Passwort benutzt (nicht bekannte Wörter oder ähnliches sondern etwas rein zufälliges, wie "§676fh(hjfKKh"), verbessert dann ein Salt-Wert immernoch die Sicherheit, oder spielt es dann keine Rolle mehr?

Vielen Dank im Voraus!

Hallo snake,

wenn die Passwort wirklich aus Zufallszeichenfolgen bestehen, bringt Salt keine Verbesserung.

herbivore

Das Salt verlängert (!) das Passwort. Erhöht also in jedem Fall die Sicherheit. Passwörter bis 8 Zeichen (Zufall oder nicht ist Wurscht) sind durchgerechnet und nicht sicher.

Salts bringen natürlich nur was gegen Brute-Force-Attacken gegen die PW-Hash-Tabellen.

Hallo svenson, hallo snake,

stimmt, ich hatte übersehen, dass man sich bei Brute-Force-Attacken vermutlich von den kurzen zu den langen Passworten durcharbeiten würde. Daher bringt Salt auch was bei komplett zufälligen, aber kurzen Passworten. Je länger das Passwort gegenüber der Maximallänge, desto weniger nützt das Salt und wenn die Maximallänge erreicht ist, nützt das Salt gar nichts mehr.

herbivore

Ein weiterer Grund für Salts ist die Tatsache, dass dadurch auch zwei gleiche PWs nicht zum gleichen Hash führen.

Alles klar, Danke!

Original von svenson
Das Salt verlängert (!) das Passwort. Erhöht also in jedem Fall die Sicherheit. Passwörter bis 8 Zeichen (Zufall oder nicht ist Wurscht) sind durchgerechnet und nicht sicher.

Salts bringen natürlich nur was gegen Brute-Force-Attacken gegen die PW-Hash-Tabellen.

Also Passwörter bis 8 Zeichen sind unsicher und ab 8 Zeichen sicher, oder wie?
Bei vielen Seiten gibts ja wenn man ein Passwort festlegen muss, einen Indikator unterhalb, der entweder rot (unsicheres PW), orange (nicht ganz unsicheres) und grün (sicheres PW) anzeigt, je nach Länge. Welche Längen entsprechen denn diesen Farben?

Vielen Dank im Voraus.

Sicher ist immer relativ. Da der Aufwand mit der Länge exponentiell steigt sind längere PWs sicherer als kürzere.

Stichwort "rainbow tables".

Ein Angriff würde folgendermaßen aussehen: Du hast deine PWs auf dem Server als Hashes gespeichert. Diese Tabelle erlangt ein Angreifer und versucht nun die zugehörigen Passwörter zu ermitteln. Mit Hilfe der "rainbox tables" (bzw. des entsprechenden Internet-Dienstes) kann du dir in 1-3 Stunden das PW zum Hash errechnen lassen. Die vorberechneten Tabellen gibt es z.Z. bis zu einer Länge von 8 Zeichen. Schon dort sind die Tabellen mehr als 100 GB groß. Für 9 Zeichen wäre es noch viel mehr.

Klar ist natürlich, dass du auch die Salts auf dem Client einigermaßen absichern musst. Wenn die ebenfalls in die Hände des Angreifers gelangen hast du nix gewonnen. Und natürlich muss die Anmeldung selbst gesichert erfolgen.

Ich mache es bei Systemen, die sicher sein müssen, so, dass der User ein vom Server zufällig generiertes Passwort bekommt, welches 10 Zeichen bestehend aus Ziffern, Klein- und Großbuchstaben bekommt. Das sind 62 ^ 10 Zeichen. Diese werden dann als Salted Hash(bei Wikipedia gucken) gespeichert. Selbst wenn einem Cracker die gesamte User-Tabelle in die Hände fällt wird kein einziges Passwort herausbekommen, auch wenn es die CIA persönlich in Kooperation mit dem KGB ist, da bin ich mir sicher!
Wenn der User sein PW vergessen hat, dann kann er ein neues anfordern. Dieses wird generiert und ihm zugesendet.

Grüße, Christoph

Aber die GUID für den Salted Hash muss man ja auch irgendwo speichern, oder? Weil Hardwareinformationen (z.B. anderer PC oder Umbau), sowie Datum und Zeit ändern sich ja.

@Quallo:
Da muss ich dir leider widersprechen.
Als erstes rechnen wir deine richtig angegebenen 62^10 Passwörter mal in Bits um:

62^10 = 2^x
dann beide Seiten logarithmieren
ln (62^10) = ln (2^x)
Logarithmengesetze
10 * ln 62 = x * ln 2
noch nach x umstellen
x = 10 * ln 62 / ln 2
Das ganze in nen Taschenrechner tippen und siehe da:
x = 59,54

Was folgt daraus? Deine Passwörter haben eine Länge von 60 Bit.
Das dürfte für den Rechner zu Hause ausreichen.
CIA, KGB, NSA, BND oder auch nur die RenderFarm von Dreamworks Pictures oder Pixar kommen da nur ins Schmunzeln.

Warum? Was zählt ist die Anzahl der Kombinationen... jetzt noch eine Anmeldesperre von 10 Minuten nach drei fehlgeschlagenen Anmeldeversuchen und eine Komplettsperre nach sagen wir mal 9 Fehlschlägen pro Tag oder 60 Fehlschlägen je Passwortgültigkeitsdauer und mit Bruteforce kommt man kein bischen weiter. Schon die 10 Minuten Sperre sollte eigentlich ausreichen um Attacken effektiv zu verhindern...

Quallo sprach aber auch nicht von Anmeldungen über den Server. Diesem Problem kann man mit Zählen der Anmeldeversuche und Sperre nach mehreren fehlgeschlagenen durchaus entgegentreten (auch wenn sich das schon wieder für einen DoS Angriff ausnutzen lässt).

Quallo meinte hingegen, dass selbst wenn die Datei mit den Hashes geklaut würde, hat er nicht viel zu befürchten. Und das stimmt definitiv nicht.

Auch dann sehe ich keine Gefahr: Selbst wenn der Mega-Rechner bloß 1/1000 s je Versuch benötigen würde, bräuchte er rein rechnerisch (bei tatsächlich zufälligen PWDs) immerhin 26614008 Jahre (ein Jahr = 365 Tage)!

Leider auch falsch.

http://www.orange.co.jp/~masaki/rc572/fratee.php
Laut dieser Liste kann ein handelsüblicher Athlon 64 x2 4600+ unter Win XP Pro ungefähr 20Mio Schlüssel pro Sekunde berechnen.

20Mio Schlüssel sind zwischen 2^{24 und 2}25 Schlüssel. Also braucht der Rechner nur noch 2^{36 bis 2}35 Sekunden.
2^36 Sekunden sind knapp 2180 Jahre FÜR EINEN EINZIGEN RECHNER.
Übliche Systeme haben aber heute locker mal 2000 CPUs.
Ergo nur noch knapp über 1 Jahr, wenn sie den kompletten Schlüsselraum absuchen müssten. Bei zufälliger Verteilung der Schlüssel müssten sie aber auch durchschnittlich nur den halben Schlüsselraum absuchen.
Desweiteren sind dann auf einmal ALLE Passwörter dieser Länge mit diesem Hash-Verfahren kompromittiert (mit anderen Worten: du brauchst die ganze Rechnerei nur einmal durchführen und nutzt dann ne Tabelle).

http://www.metaner.de/1pw/brute-force.html
Hier haben sie mit den Werten vom obigen Link einige Berechnungen zur nötigen Dauer bei verschiedenen Passwörtern angestellt.
Bei unserem Beispiel beläuft sich die Dauer auf 882.73 Jahre für EINEN Rechner. Nimm einfach mal nen Superrechner mit 10000 Prozessoren oder nen Cluster mit 1000 Rechnern und du siehst, das dieses Problem sehr wohl besteht.

Verfügt man jetzt durch Würmer und Trojaner über ein Botnet mit ca. 200.000 Rechnern, kann man nicht nur massig Kohle durch Spam verdienen, sondern auch bezahlte dDoS-Attacken fahren (oder Schutzgeld erpressen) und so ganz nebenbei noch ein paar Passörter berechnen.

http://www.distributed.net/des/
Schau dir mal den DES-III Wettbewerb an.
Und die Diagramme der Auswertungen.
http://n0cgi.distributed.net/statistics/des3/
Du erkennst dort, das zum Ende des Wettbewerbs knapp 250 Milliarden Schlüssel pro Sekunde generiert wurden. Damit wurden knapp 30% des 56-bittigen Schlüsselraums innerhalb von nicht mal zwei Tagen abgegrast.
Und das was Januar 1999, lange vor dem "GigaHertz-Wettrennen".

Sprachlos... 8o

PS. Ich gebe zu, dass ich bei obigen Ausführungen nicht auf den Salt eingegangen bin. Die Bits des Salt müssen also zu den Bits des Passwortes hinzugerechnet werden, so dass sich mit jedem Bit Salt der Schlüsselraum - und damit die Rechenzeit - verdoppelt.
Allerdings gilt das auch nur, wenn nicht das (mittlerweile) veraltete SHA1 zum Einsatz kommt.
Dieses wurde bereits kompromiert, was auch alle Nachfolger gefährden könnte.
http://www.heise.de/security/news/meldung/56507
http://www.heise.de/security/artikel/56555
http://www.heise.de/security/news/meldung/56428

Original von Borg
Leider auch falsch.

>
Laut dieser Liste kann ein handelsüblicher Athlon 64 x2 4600+ unter Win XP Pro ungefähr 20Mio Schlüssel pro Sekunde berechnen.

Welche Methode nehmen die denn? SHA1?
Ich denke nicht, dass du eine Aussage über die Versuche pro Sekunde machen kannst ohne die Länge des Salt und die verwendete Hash-Methode zu kennen. Das hast du leider nicht beachtet. Somit ist der Rest nur noch eine hübsche Rechnung, aber vielen Dank für deine Mühe.

Original von Borg

20Mio Schlüssel sind zwischen 2^{24 und 2}25 Schlüssel. Also braucht der Rechner nur noch 2^{36 bis 2}35 Sekunden.
2^36 Sekunden sind knapp 2180 Jahre FÜR EINEN EINZIGEN RECHNER.
Übliche Systeme haben aber heute locker mal 2000 CPUs.
Ergo nur noch knapp über 1 Jahr, wenn sie den kompletten Schlüsselraum absuchen müssten. Bei zufälliger Verteilung der Schlüssel müssten sie aber auch durchschnittlich nur den halben Schlüsselraum absuchen.
Desweiteren sind dann auf einmal ALLE Passwörter dieser Länge mit diesem Hash-Verfahren kompromittiert (mit anderen Worten: du brauchst die ganze Rechnerei nur einmal durchführen und nutzt dann ne Tabelle).

>
Hier haben sie mit den Werten vom obigen Link einige Berechnungen zur nötigen Dauer bei verschiedenen Passwörtern angestellt.
Bei unserem Beispiel beläuft sich die Dauer auf 882.73 Jahre für EINEN Rechner. Nimm einfach mal nen Superrechner mit 10000 Prozessoren oder nen Cluster mit 1000 Rechnern und du siehst, das dieses Problem sehr wohl besteht.

Verfügt man jetzt durch Würmer und Trojaner über ein Botnet mit ca. 200.000 Rechnern, kann man nicht nur massig Kohle durch Spam verdienen, sondern auch bezahlte dDoS-Attacken fahren (oder Schutzgeld erpressen) und so ganz nebenbei noch ein paar Passörter berechnen.

>
Schau dir mal den DES-III Wettbewerb an.
Und die Diagramme der Auswertungen.

>
Du erkennst dort, das zum Ende des Wettbewerbs knapp 250 Milliarden Schlüssel pro Sekunde generiert wurden. Damit wurden knapp 30% des 56-bittigen Schlüsselraums abgegrast.
Und das was Januar 1999, lange vor dem "GigaHertz-Wettrennen".

Mit nem Salt kannst du ruhig den kompletten Schlüsselraum für SHA1 für alle möglichen Passwörter haben....

Original von Borg
PS. Ich gebe zu, dass ich bei obigen Ausführungen nicht auf den Salt eingegangen bin. Die Bits des Salt müssen also zu den Bits des Passwortes hinzugerechnet werden, so dass sich mit jedem Bit Salt der Schlüsselraum - und damit die Rechenzeit - verdoppelt.
Allerdings gilt das auch nur, wenn nicht das (mittlerweile) veraltete SHA1 zum Einsatz kommt.
Dieses wurde bereits kompromiert, was auch alle Nachfolger gefährden könnte.

>

>

>

Das stimmt nicht so ganz. Da sich der Schlüsselraum durch den Salt nicht verhindert, wird nur die Rechenzeit für den Hash erhöht und es helfen keine Rainbow-Attacken.
Ausserdem haben zwei gleiche Passwörter nicht den gleichen Hash-Wert.

Meines Erachtens ist die SHA1 durch den jetzt gefundenen Fehler bei 2 hoch 63 Möglichkeiten bis Kollision angelangt. Da meine Passwörter nur 2 hoch 60 Möglichkeiten haben, ist das noch egal. Aber ich denke trotzdem, dass es SHA 256 oder mehr wird.

Grüße, Christoph

(1)
Wie auf der Seite steht, handelt es sich dabei um RC5-72.
Durch die geringe Schlüssellänge ist dieses deutlich schneller zu berechnen als SHA1.
Und es ist natürlich kein Hash sondern ein Stromchiffre.
Daher ist das eigentlich nicht direkt vergleichbar.

(2)
Es ging auch primär darum, zu zeigen, dass

Selbst wenn einem Cracker die gesamte User-Tabelle in die Hände fällt wird kein einziges Passwort herausbekommen, auch wenn es die CIA persönlich in Kooperation mit dem KGB ist, da bin ich mir sicher!

eine ziemlich gewagte Aussage ist.

(3)
Wie schon gesagt, habe ich bei meinem ersten Post den Salt nicht beachtet.
Nun wird durch die Verwendung von Salts der Schlüsselraum noch deutlich vergößert.
Zum jetzigen Zeitpunkt kann das Verfahren (gerade, da es bislang keinen Nachfolger von SHA1 gibt), das du beschreibst, als ausreichend sicher angesehen werden.
Allerdings gibt es keine Garantie, dass SHA1 nicht weiter geknackt wird, die Implementierung fehlerhaft ist und was einem sonst noch so alles einfällt.

(4)
Als Quintessenz kann stehen bleiben:
Absolute Sicherheit gibt es nicht. Wer so etwas behauptet hat a) keine Ahnung oder b) lügt wissentlich.

Natürlich gibt es keine absolute Sicherheit.

Der Schlüsselraum wird meines erachtens durch den Salt nicht erhöht. Es bleibt bei 62 hoch 10 Möglichkeiten. Die Berechnung dauert natürlich länger.

Stimmt, du hast recht.

Der Schlüsselraum wird natürlich nicht größer, da man den Salt ja ebenso wie den Hash kennt und damit weiterhin nur 60 Bit "raten" muss.

Es bleibt aber nur die Brute Force Variante über, da durch den Salt Wörterbuch-Attacken ausgeschlossen werden.

Da bei dir aber die Passwörter zufällig ermittelt werden und vom Benutzer nicht verändert werden können (jedenfalls habe ich das so verstanden), ist der Salt doch eigentlich unnötig, oder?

Ja, das stimmt soweit schon. Rainbow-Attacken und gleiche Passwörter, die dann einen gleichen Hash ergeben sind wohl auszuschließen bei dem Verfahren.
Aber, falls das mal geändert wird, und Passwörter frei gwählt werden können, bin ich auf jeden Fall auf der sicheren Seite. Da das System eine Laufzeit von einigen Jahren hat, kann sich soetwas durchaus mal ändern.

Nette Diskussion...

Leider kenne ich mich mit diesen Möglichkeiten, Verschlüsselungen zu knacken nicht aus. Ich erläutere einfach mal näher um was es geht, ich habe ein Programm zum Verschlüsseln von Dateien geschrieben, wo man ein Passwort zum Verschlüsseln angeben muss. Mit Hilfe der PasswordDeriveBytes-Klasse leite ich einen 32-stelligen Key und einen 16-stelligen IV zur Verschlüsselung ab (RSA-Verschlüsselung).
Macht es dort Sinn (ist es sinnvoll), einen Salt-Wert zu verwenden?

@Snake:
Bei Verwendung des RSA auf jeden Fall. Die zusätzliche Sicherheit kann u.U. gering erscheinen, da RSA aber für Transport gemacht ist macht auch ein Quentchen mehr Sicherheit ne Menge aus.
Nicht ganz ernst gemeint... 😉

Allerdings hab ich ein Verständnisproblem. Ich versteh nicht wo bei RSA ein SALT sinnvoll wär, da die ausgetauschten Schlüssel eh public sind...

Ähm, Salt und RSA passt nicht unbedingt. Es gibt zwar diverse Kombinationen um einen Vorgang sicherer zu machen(zB:Authentifizierung), aber keine derartigen Kreuzungen.
Ein Hash ist zwar Sicherheitsrelevant aber keine Verschlüsselung, sondern "nur" Signatur. Du hast wohl einfach was verwechselt.