Dauer bis Passwort geknackt ist

[FatManStanding]

tach,

nur eine verständnisfrage, kein konkretes problem.

angenommen jemand will ein passwort knacken einfach indem er jedes möglich passwort durchprobiert (egal wieviel jahrhunderte das ggf. dauert). dann man man ausrechnen wie lange er braucht indem ich ausrechnen wieviel mögliche kombinationen es gibt und wieviel passwörter ein rechner pro sekunde erstellen kann. das geht aber nur, wenn ich weiß wieviel zeichen beim passwort verwendet werden. wenn mein passwort

12345678

lautet und jemand

123456789

versucht, geht es nicht. wenn ich nun ausrechnen will wie lange das knacken dauert, müsste ich dann nicht jedes mögliche passwort bei jeder möglichen passwortlänge berücksichtigen? also erst alle passwörter mit 63 zeichen (z. b. bei wpa2), dann alle mit 62, dann alle mit 61? oder erkennt man schon aus den verschlüsselten daten die passwortlänge?

 

[tollertyp]

Ich würde annehmen dass man eher von wenig Zeichen zu vielen geht beim Versuch zu knacken als umgekehrt.

Natürlich erschwert es den Angriff, wenn die Passwortlänge unbekannt ist (und auch keine Rückschlüsse auf die Länge mögllch sind).

 

[FatManStanding]

erstmal egal in welcher richtung man geht. es geht um das prinzip. ist aus den verschlüsselten daten zu erkennen wieviel zeichen ein passwort hat?

 

[Masamune2]

Die Passwortlänge ist vorher nicht bekannt. Solang du keine Infos hast welche Zeichen im Passwort vorkommen könnten musst du von allen ausgehen was selbst bei kürzeren Kennwörtern zu einer irre langen Zeit führt.
In der Praxis versucht man erst mit Wörterbüchern zu knacken, dann kombiniert man die Wörter im Wörterbuch mit beliebten Zahlen und anderen Wörtern und erst danach würde man anfangen jede theoretisch mögliche Kombination durchzuraten.

 

[xxMuahdibxx]

Ansonsten gibt's Webseiten welche dir das ausrechnen..

 

[MinaB.]

Ich bin mir relativ sicher, dass man aus (richtig) verschlüsselten Daten, nicht die Länge der Unsprungsdaten haerausfinden kann. Zudem gehe ich davon aus, das Passwort-knack-algorythmen bei der wahrscheinlichsten Passwortlänge starten und sich dan davon wegbewegen.

 

[tollertyp]

Die Richtung ist alles andere als egal... aber ja, man müsste alles probieren.

Deshalb wird auch kaum jemand solche Angriffe fahren. Stattdessen wird eher versucht, "Lücken" und Eigenschaften zu nutzen, und mit Lücken meine ich jetzt nicht Backdoors oder Bugs, sondern mitunter halt einfach kryptographisches Verhalten.

Einfaches Beispeil bei einer Verschiebe-Chiffre: Da würde man eher eine Analyse über die Zeichen machen und dann über Statistiken den richtigen Schlüssel finden...

 

[Bonanca]

wenn ich nun ausrechnen will wie lange das knacken dauert, müsste ich dann nicht jedes mögliche passwort bei jeder möglichen passwortlänge berücksichtigen?

Du musst ja nur die Passwörter kürzerer Länge berücksichtigen und die Passwörter gleicher Länge.

Die Passwörter kürzerer Länge machen aber meist <10%, meist sogar <5% der gesamten Dauer aus, simple Kombinatorik.
Deswegen geht man auch von kurz nach lang.

 

[SimSon]

Handelt es sich bei deiner Frage um Hausaufgaben?
Mir kommt die Frage aus meiner IT Lehre so bekannt vor.

 

[Bonanca]

Handelt es sich bei deiner Frage um Hausaufgaben?

Dann wäre das eine sehr unspezifische Frage.
Die Fragen die wir hatten waren tatsächlich "Wieviele PW-Kombinationen ergeben sich bei einer PW-Länge zwischen X und Y, wenn Z Zeichen erlaubt sind?" mit anschließender "Bei einer Hashrate von W Hashes/Sekunde: Wie lange dauert es die jeweilige Anzahl an Passwörtern zu hashen?".
Und da ist beides ja nur Zahlen in Formeln einsetzen.

Im Moment erschließt sich mir daher noch nicht ganz, wo der TE hin möchte.

 

[Nixdorf]

wenn ich nun ausrechnen will wie lange das knacken dauert, müsste ich dann nicht jedes mögliche passwort bei jeder möglichen passwortlänge berücksichtigen?

Ja, muss man. Allerdings hätte der Angreifer in deinem Beispiel die "12345678" wahrscheinlich vor der "123456789" ausprobiert, weil bei Brute-Force-Angriffen Passwörter mit aufsteigender Länge durch getestet werden. Der Beispiel-Fall tritt dann gar nicht auf.

Und davon abgesehen stehen diese beiden konkreten Nummernpasswörter natürlich in Rainbow-Tables für die gängigen Algorithmen, würden also über Wörterbuchattacken noch vor dem Alphabet-Brute-Forcing geknackt.

ist aus den verschlüsselten daten zu erkennen wieviel zeichen ein passwort hat?

Nein. Zumindest nicht, wenn die Verschlüsselung nicht irgendwelchen kolossalen Schwachsinn macht. Denkbar wäre, dass ein Programm die Verschlüsselung durchführt, und dabei fest nach einem achtstelligen Code fragt. Ein Angreifer prüft dann natürlich abweichend von der aufsteigenden Regel zunächst achtstellige Kombinationen durch. Und wenn das Programm die Eingabe tatsächlich unverändert als Passwort verwendet, dann liegt der Angreifer mit seiner Einschätzung sogar richtig.

 

[Joe Dalton]

Im Moment erschließt sich mir daher noch nicht ganz, wo der TE hin möchte.

So wie das ganze konstruiert ist, würde ich fast darauf wetten, dass es darum geht kurze Passwörter zu rechtfertigen.

Ausserdem wird bei dem Versuch der Zeitrechnerei vergessen, dass damit nur eine Abschätzung zur maximalen Dauer möglich ist. Es müssen nicht alle denkbaren Kombinationen geprüft werden, sondern nur bis zum ersten Treffer.

 

[wern001]

Kommt drauf an wie schnell der gegenüber das beantworten kann und wieviel rechenleistung man selbst hat.
jedenfalls so Wörterbuchattacken dauern nur wenige Sekunden.
Hat man alles lokal. z.b. verschlüsselte Zip-Datei Sind je nach PC ca 1-5 Mio PWs pro sekunde möglich.

 

[Amaoto]

wenn ich nun ausrechnen will wie lange das knacken dauert, müsste ich dann nicht jedes mögliche passwort bei jeder möglichen passwortlänge berücksichtigen?

Nein, sondern nur die Passwörter, die man ausprobiert, bis man das richtige hat. Deswegen fängt man mit den wahrscheinlicheren an.

 

[Nixdorf]

Es müssen nicht alle denkbaren Kombinationen geprüft werden, sondern nur bis zum ersten Treffer.

Wenn wir hier schon von der Theorie in die Praxis wechseln, dann kommen hier mal ein paar ganz praktische Überlegungen. Den Themenkomplex lokale Angriffe, z.B. auf verschlüsselte ZIP-Dateien, PDFs oder Veracrypt, hat @wern001 gerade schon besprochen. Ich gehe nun mal auf Angriffe aus dem Bereich Internet näher ein.

Wenn der Angreifer hier die Möglichkeit für einen Brute-Force-Angriff hat, dann liegt offenbar bereits ein Passworthash vor, zum Beispiel aus einem Leak. Liegt der aber nicht vor, dann fallen all die Schätzungen zu Hashraten von Prozessoren oder GPUs hinten runter, denn die Geschwindigkeit für Brute-Force-Angriffe ist dann durch die Verarbeitungszeit eines Login-Versuchs beim konkreten Ziel beschränkt. Oft kommen dann noch Zwangswartezeiten nach einigen Fehlversuchen dazu.

Es geht also bei all diesen Gedankenspielen immer um welche, wo der Angreifer bereits einen Hash hat. Daraus ergeben sich zwei Schlussfolgerungen:

1. In dem Leak können auch bereits alle sicherheitsrelevanten Daten sein, die es beim Anbieter gab, bei dem das Leak auftrat. Ein Knacken des Passworts ist also womöglich gar nicht mehr notwendig.
2. Man knackt dann nur noch für den Fall, dass das Passwort auch an anderen Stellen genutzt wurde. Angreifer spekulieren darauf, dass beim Kaffee- oder Hundefutter-Shop der gleiche Zugang genutzt wurde wie zum Beispiel bei eBay.

Die wichtigste Forderung ist also noch vor der Passwortlänge: Verwende niemals dasselbe Passwort an mehreren Stellen!

So wie das ganze konstruiert ist, würde ich fast darauf wetten, dass es darum geht kurze Passwörter zu rechtfertigen.

In einigen Fällen kann man die sogar rechtfertigen. Das hängt aber nicht von der Logik der Durchprobier-Reihenfolge ab, sondern davon, dass das Brute-Forcing durch einen sehr langsamen und speicherintensiven Hash-Algorithmus sehr ineffizient ist. Bei einer KeePass-Datenbank kann man das detailliert einstellen und dann auch ein vergleichsweise kompaktes Masterpasswort rechtfertigen.

In den meisten anderen Fällen weiß man aber nicht, welche Sicherheitsmaßnahmen zum Schutz des Passworts ein Anbieter ergreift. Und dann kann man kurze Passwörter nicht rechtfertigen. Der einzige Kontrollmechanismus, den man als Nutzer dann hat, ist eine hohe Passwortlänge.

 

[eltono91]

Eigentlich kann man doch gar nicht ausrechnen wie lange es dauert ein Passwort zu knacken, weil das Passwort ist ja unbekannt. Theoretisch könnte schon der erste Versuch der richtige sein, dann hab ich es in unter einer Sekunde geknackt. Es könnte aber auch die letzte Kombination sein, dann dauert es vielleicht Monate.

Oder anders: Eigentlich kann man doch nur berechnen wie lange es dauern würde alle möglichen Kombinationen durchzugehen, weil man ja nicht weiß beim wievielten Versuch die Kombination richtig ist.

Oder verstehe ich da was falsch?

 

[tollertyp]

Selbst wenn es eine Hausaufgaben-motivierte Frage wäre, wäre diese Form der Fragestellung dafür absolut okay.

@eltono91: Man berechnet häufig die im Mittel zu erwartende Zeit. Die ergibt sich dann aus dem Durchprobieren aller Kombinationen. Da man aber mit Glück bereits am Anfang und mich Pech erst am Ende das richtige Passwort hat, wird der Wert halbiert, weil man im Mittel halt die Hälfte der Versuche braucht.

Worst Case ist eben alle, und Best Case wäre halt einer.

 

[eltono91]

@tollertyp
Macht Sinn, landet man dann im Grunde bei einer Normalverteilung.

Das man da einen gewissen Zeitraum definieren kann war mir klar. Wollte eigentlich darauf hinaus, dass die Ausgangsfrage (Wie lange braucht man um ein Passwort zu knacken?) schon abwägig ist, weil exakt bestimmen kann man das eh nicht. Man kann nur anhand der zur Verfügung stehenden Informationen einen Zeitraum von x bis y definieren.

 

[tollertyp]

Richtig, es ist auch keine exakte Frage gewesen, sondern ging mehr um das Verständnis.

Und die Erkenntnis, dass alle Varianten zu probieren selten erfolgversprechend ist...

 

[Bonanca]

landet man dann im Grunde bei einer Normalverteilung.

Wohl eher Gleichverteilung. Außer du betrachtest die Summe mehrerer (bis zum Erfolg durchgeführter) Brute-Force attacken