Hallo,
ich habe früher mal Truecrypt genutzt und kann mich noch daran erinnern,
dass die Empfehlung dort bei mindestens 20 Zeichen lag. Schon damals
habe ich mich gefragt, wie viele Nutzer wohl wirklich jedes mal 20
Zeichen und mehr eintippen.
Nun überlege ich aus akademischem Interesse, wie lang denn heutzutage
Passwörter sein müssen, damit eine symmetrische Verschlüsselung sicher
ist? Deren Mindest-Länge müsste ja auch maßgeblich vom verwendeten
Hash-Algorithmus abhängen, da auf der binären Schlüssel-Ebene (fast)
jede Bit-Kombination möglich ist. Also wenn ich z.B. den Hash-Algo so
wähle, dass ich für das Entschlüsseln des Schlüssels mit einem Core i3
ca. 0,1 Sekunden warten muss, dann müsste ich bei einem 10-Stelligen
möglichst zufälligen Passwort(Kleinbuchstaben + Zahlen angenommen,
vereinfacht also ein Alphabet von 26 + 10 Zeichen) immer noch über 11
Millionen Jahre mit dem gleichen Core i3 Brute-Forcen, wenn ich mich
nicht verrechnet habe.
Wie sieht es denn aktuell mit den Hash-Algos aus? Welche Passwortlängen
sind aus mathematischer Sicht sinnvoll und spielt das Verhältnis
zwischen Nutzer-Rechenpower und Angreifer-Rechenpower(z.B. ein Botnetz
oder eine FPGA-Matrix) dabei eine Rolle?
Ruth schrieb:> Hallo,> ich habe früher mal Truecrypt genutzt und kann mich noch daran erinnern,> dass die Empfehlung dort bei mindestens 20 Zeichen lag. Schon damals> habe ich mich gefragt, wie viele Nutzer wohl wirklich jedes mal 20> Zeichen und mehr eintippen.> Nun überlege ich aus akademischem Interesse, wie lang denn heutzutage> Passwörter sein müssen, damit eine symmetrische Verschlüsselung sicher> ist?
Da müsstest Du erst einmal ganz akademisch definieren, was Du unter
Sicherheit verstehst.
> Deren Mindest-Länge müsste ja auch maßgeblich vom verwendeten> Hash-Algorithmus abhängen, da auf der binären Schlüssel-Ebene (fast)> jede Bit-Kombination möglich ist.
Warum sollte die Passwortlänge vom Hash-Algorithmus abhängig sein?
> Also wenn ich z.B. den Hash-Algo so> wähle, dass ich für das Entschlüsseln des Schlüssels mit einem Core i3> ca. 0,1 Sekunden warten muss, dann müsste ich bei einem 10-Stelligen> möglichst zufälligen Passwort(Kleinbuchstaben + Zahlen angenommen,> vereinfacht also ein Alphabet von 26 + 10 Zeichen) immer noch über 11> Millionen Jahre mit dem gleichen Core i3 Brute-Forcen, wenn ich mich> nicht verrechnet habe.
Seit wann bestimmst Du über die Laufzeit eines Hash-Algorithmus?
>> Wie sieht es denn aktuell mit den Hash-Algos aus? Welche Passwortlängen> sind aus mathematischer Sicht sinnvoll
Was verstehst Du unter "mathematisch sinnvoll" (siehe auch oben
"Sicherheit")?
> und spielt das Verhältnis> zwischen Nutzer-Rechenpower und Angreifer-Rechenpower(z.B. ein Botnetz> oder eine FPGA-Matrix) dabei eine Rolle?
Ja, natürlich. Aber Du kennst nicht die Rechenleistung des Angreifers.
Irgend eine 256 Bit Verschluesselung hebelt man einfacher als per brute
force Knacken aus.
zB kann man die ueblichen Protokolle duch mangelhafte Implementation,
resp Konfiguration auf einen tieferen Standard zwingen. Dh, dein Rechner
kann zwar AES, die Gegenstelle, oder eine Zwischenstation behauptet nur
XOR, oder gar nichts zu koennen. Dann laeuft die Kommunikation ueber
XOR, resp ueber gar nichts.
Dann sollte man, sofern einem etwas an sicheren Nachrichten liegt,
amerikanische Unternehmen vermeiden, resp aufpassen was man dort drueber
laesst.
Ruth schrieb:> Also wenn ich z.B. den Hash-Algo so> wähle, dass ich für das Entschlüsseln
Hashing != Verschlüsselung
Einen Hashwert kannst du nicht entschlüsseln. Eine Hash-Funktion ist
eine mathematische Einwegfunktion. Aus dem Ergebnis der Funktion kannst
du nicht die Eingabe errechnen, selbst wenn du den Algorithmus kennst.
Du kannst das Passwort maximal erraten, genauer gesagt: Du kannst eine
Zeichenfolge erraten (siehe: Rainbow-Tables), die den selben Hashwert
liefert wie das Passwort, die Zeichenfolge muss aber nicht zwingend das
Passwort sein, siehe MD5.
Ruth schrieb:> Deren Mindest-Länge müsste ja auch maßgeblich vom verwendeten> Hash-Algorithmus abhängen
Die Länge des Passwortes ist völlig egal für den Hashalgorithmus. Denn
das ist das Ziel einer Einwegfunktion:
Es ist egal wie lang dein Passwort ist, 1 Zeichen oder 2000 Zeichen sind
schnurz egal, es kommt ein Wert mit fester Länge raus. Deswegen kannst
du die Funktion auch nicht umdrehen, da du nicht weißt, wie viele
Zeichen reingegeben wurden. Gibts du natürlich zu wenig Zeichen rein,
kann man das erkennen, da die fehlenden Zeichen ja mit irgendwas
aufgefüllt werden müssen. Und da das ja jedesmal das selbe "irgendwas"
sein muss...
Ruth schrieb:> 10-Stelligen> möglichst zufälligen Passwort(Kleinbuchstaben + Zahlen angenommen,> vereinfacht also ein Alphabet von 26 + 10 Zeichen)
Dann hast du 36^10 Passwordmöglichkeiten. Bei 0,1 Sekunde pro
Kombination schaffst du an 365 Tagen 315.360.000 kombinationen, macht
dann ~11.6 Milliarden Jahren. Ja, deine Rechnung stimmt soweit.
Das ganze funktioniert aber nur, wenn das Passwort die letze Kombination
ist, die ausprobiert wird, also der worst-case Fall. Ist das Passwort
aber die erste Kombination... naja, dann ist das ganze in 0.1 Sekunde
gegessen.
Wenn du jetzt aber nicht einen popeligen i3 nimmst sondern
Grafikkarten/FPGA/ASIC oder einfach mal 500 Millionen Router kaperst,
die 24/7 eingeschaltet sind, dann werden aus deinen 11.6 Milliarden
vielleicht schon nur noch Stunden oder Sekunden.
Mal angenommen ein Router würde statt 0,1 Sekunden 1 Sekunden brauchen,
bei einem botnetz mit 500 Millionen macht das dann ca. 0,23 Jahre.
36^10 / (500.000.000x60x60x24x365)
Router als Botnetz:
http://www.heise.de/newsticker/meldung/Gehackte-Router-als-Bot-Netz-2515682.html
So abwegig ist die Idee mit den Routern also gar nicht, auch wenn eine
Zahl von 500 Millionen vielleicht etwas hochgegriffen ist.
Wie schnell Grafikkarten/FPGA/ASIC sind, kannst du dir selbst überlegen.
Und jetzt spielen wir das ganze mal für eine Länge von 20 durch:
Länge von 20 -> 36^20 Möglichkeiten
i3 mit 0,1 Sekunde/Kombination -> 4.23x10^22 Jahre
500 Millionen Router mit 1 Sekunde/Kombination -> 8,477x10^14 Jahre
Rechnungen ohne Gewähr!
Ruth schrieb:> Millionen JahreKaj G. schrieb:> Rechnungen ohne Gewähr!
Wenn durch einen Bug nicht mal das lange PW sondern NUR WENIGE Zeichen
davon ausgewertet wurden, besteht natürlich nur scheinbare Sicherheit
durch größere PW-Länge. Leider war der beschriebene Bug der Firma N.v...
echt vor einigen Jahren. Genau deswegen sollten Wissende auch die
Quellen der Programme genauer untersuchen (können). Sonst werden aus
Millionen Jahren wenige Minuten.
Kaj G. schrieb:> Bei 0,1 Sekunde pro> Kombination schaffst du an 365 Tagen 315.360.000 kombinationen, macht> dann ~11.6 Milliarden Jahren.
Hupsi, muss Millionen heißen. :-/
Kaj G. schrieb:> dann werden aus deinen 11.6 Milliarden
Hier ebenso. :(
Kaj G. schrieb:> Gibts du natürlich zu wenig Zeichen rein,> kann man das erkennen, da die fehlenden Zeichen ja mit irgendwas> aufgefüllt werden müssen. Und da das ja jedesmal das selbe "irgendwas"> sein muss...
Das stellt kein problem dar, weil hashfunktionen chaotich sind. Ein
anderes Zeichen oder andere länge = komplett anderer hash.
Die geschwindigkeit um einen hash zu knacken ist von 2 faktoren
abhängig:
1) Länge
2) ob er gesalzen wurde
Wenn er nicht gesalzen wurde kann man einen möglichen uhrsprungswert in
wenigen us abfragen, dazu braucht man nur eine Datenbank mit der ersten
passenden Zeichenfolge für jeden hash und man hat mit 2 tabellenabfragen
und etwas glück das gesuchte passwort. Sowas müsste auf einer TB
festplatte platz haben. (bei sha256)
Wenn es gesalzen wurde braucht man den salt auchnoch. Dann muss man sich
eine rainbow table aufbauen, und je nach algorzthmus dauert das zwichen
einigen Minuten bis Tagen. Bei bcrypt kann man das da gleich vergessen
(variable anzagl hashzyklen, omg)
PS: Auch bei Routern sind 1s/hash stark untertrieben (ausser vielleicht
bei bcrypt bei entsprechender Anzahl zyklen)
Hallo,
genau genommen haben starke Verschlüsselung und Passwortlänge wenig
miteinander zu tun: die üblichen Programme verwenden sowieso eine
bestimmte Schlüssellänge, egal wie lang das Passwort ist.
Einerseits: ein knackbarer Verschlüsselungsalgorithmus ist eben
knackbar, egal mit welchem Passwort.
Andrerseits: eine starke Verschlüsselung nützt wenig, wenn das Passwort
5 Zeichen lang ist und mausi lautet.
Man braucht also einen sicheren Algorithmus UND ein starkes Passwort.
Vermutlich ist das Missverständnis, dass ein längeres Passwort einen
längeren Schlüssel ergibt, aber das ist i.A. nicht der Fall.
Georg
Georg schrieb:> Vermutlich ist das Missverständnis, dass ein längeres Passwort einen> längeren Schlüssel ergibt, aber das ist i.A. nicht der Fall.
Es hat mit den erwähnten Rainbow-Tables zu tun. Deren Grösse hängt mit
der maximalen Länge damit zu ermittelnder Passwörter zusammen. Wobei das
auch in Zusammenhang mit der Zeichensatzauswahl steht. Grossbuchstaben
oder Sonderzeichen führen bei gleicher Länge zu viel grösseren Tables.
Wenn ein Passwort also länger ist, als praktikable Rainbow-Tables zu
dessen Ermittlung sein können, dann fällt dieser Ansatz aus.
