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 Jahre Kaj 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)
:
Bearbeitet durch User
Daniel A. schrieb: > Sowas müsste auf einer TB festplatte platz haben. (bei sha256) Bei SHA1 und maximal 10 Zeichen bei klein geschriebenen alphanumerischen Passwörtern passt das: http://project-rainbowcrack.com/table.htm
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.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.