Passwörter (Komplexität/Länge)

Zeitmangel

Experte
Thread Starter
Mitglied seit
23.08.2020
Beiträge
2.135
Moin,.

Ich bin über diesen auch schon mittlerweile alten Schinken gestolpert (Link am Ende) und außer all den Binseweisheiten - nicht unbedingt verkehrten - fiel mir mal was anderes auf.

Der Graziani hab ich mal an einer anderen Stelle gelesen damals, und meine, die hatten da eine Rick aus paar Titan X (preisbewusst?) Ob Titan Xp? Ich kann mich leider nicht mehr 100% erinnern. Und er erzählt in diesem Artikel, für 16 Zeichen ohne (wohl) Sonderzeichen, bräuchte er damals 3 Monate.

In dem Kontext und Verlauf des Gesprächs ist das für mich Groß/Klein mit paar Zahlen? 16 Zeichen, 3 Monate, brute-force. Das wäre doch von der Zeit her ULTRAKURZ oder übersehe ich etwas?

 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.

In dem Artikel wird nicht erwähnt, welche Art von Brute-Force angewandt wird.
Vermutlich ist damit gemeint eine Kollision mit einem Passworthash zu finden. Dazu muss man aber erstmal an den entsprechenden Hash kommen. Direkt mit Bruteforce in einen Account einloggen wird idR schon auf anderer Ebene abgefangen, z.B. immer längere Wartezeiten zwischen Loginversuchen oder der Login wird nach X Versuchen direkt gesperrt.

3 Monate Rechenzeit für sowas brauchen ist aus aktueller Sicht eher verdammt lang.
 
Ist das nicht schon 16^62?
 
3 Monate Rechenzeit für sowas brauchen ist aus aktueller Sicht eher verdammt lang.
Also... :rolleyes2: Crypto ist nicht mehr sicher, wenn man es zum Zeitpunkt innerhalb von 70 Jahren knacken könnte, aber 3 Monate für ein Passwort wäre lang?? Was ist nochmal der Zugang für Crypto? Etwa Passwörter? :unsure:
 
Also... :rolleyes2: Crypto ist nicht mehr sicher, wenn man es zum Zeitpunkt innerhalb von 70 Jahren knacken könnte,
Wo kommt das jetzt her? Was hat das hiermit zu tun?

aber 3 Monate für ein Passwort wäre lang??
Ja, 3 Monate um ein Passwort zu knacken ist lang und dauert in diesem Fall auch nur so lang, weil es eben 16 Zeichen sind. Die meisten Passworter haben keine 16 Zeichen und sind oftmals in wenigen Tagen, wenn nicht sogar nur Stunden geknackt.
Nochmal abgesehen davon, das sich die Rechenleistung aktueller GPUs grob geschätzt mittlerweile verdoppelt hat und davon ausgehend wären es somit auf einer modernen GPU keine 3 Monate mehr, sondern eher nur noch 1,5 Monate.
 
Was hat das hiermit zu tun?
Hä? Gibt es sowas wie eine passwortlose Cryptographie? Wie kommt man da an die verschlüsselten Daten wieder dran? (gespeicherte Retinas oder Wehnen(Hashes) usw. sind für mich das gleiche)

edit:
Hab ich echt vergessen hinzuzufügen, daß es nicht alleine um Facebook-Kontos geht? :rolleyes2:
 
Hä? Gibt es sowas wie eine passwortlose Cryptographie? Wie kommt man dann an die Verschlüsselten Daten wieder dran? :rolleyes2:
An Cryptographie ist ein Passwort (oder sogar mehrere) beteiligt, ein Passwort alleine hat aber noch nicht viel mit Cryptographie zu tun.

Passwörter werden nicht verschlüsselt sondern gehashed. Das sind Ein-Weg-Rechenverfahren. Einen Hash kann man nicht "entschlüsseln", man kann ihn nur brute-forcen.
Bei Cryptographie werden Daten mit einem Schlüssel verschlüsselt, aber die will man ja auch wieder entschlüsseln können.
Und dazu verwendet man heutzutage meist asymmetrische Schlüsselpaare (ein Schlüssel zum VERschlüsseln, aber ein anderer Schlüssel/Passwort zum ENTschlüsseln) und nicht umsonst sehr lange Schlüssel (4096Bit sind nicht unüblich).

Ein Passwort zu "erraten" mit dem man sich in einen Account einloggen kann, ist also ein ganz anderes Thema, als verschlüsselte Daten entschlüsseln zu können.
 
Passwörter werden nicht verschlüsselt sondern gehashed.
Das ist mir klar... Es geht darum wieviel Tausend Mal schwächer grad diese Funktion gegenüber Crypto selbst ausschaut (?)

edit:
Ich glaub symetrische und asymetrische Verfahren brauchen wir jetzt nicht auch noch ins Spiel bringen. Es ging nur um den Zugangsschutz zu Crypto durch Passwörter. Auch hin und her Salzen ist das andere. Geht nur um das wofür der Benutzer sich entscheidet.
Die 16 Zeichen waren doch auch nicht einfach nur simpelst gehashed (?) Es geht schon um reale Verfahren die man anwendet.

Ja, ich verpeiel wohl grad etwas. Kein Ding. nur was? 3 Monate ist garnichts, wenn dir einer z.B. die KeePass Datenbank stibitzt. Wo die Superduper-Passwörter liegen.
 
Zuletzt bearbeitet:
Das hängt davon ab mit welchem Algorithmus und wie gehashed wird. MD5 gilt mittlerweile als sehr unsicher, SHA (in diversen Varianten) gilt als wesentlich sicherer. Mit Salt oder ohne?
Keine Ahnung was man da aktuell so verwendet.... oder was welcher Anbieter tatsächlich einsetzt.

Auch bei Crypto gibts hunderte, tausende unterschiedliche Verfahren... man kann das also alles sowieso nicht 1:1 vergleichen.

Und der Einsatzzweck ist ja auch ein ganz anderer. Bei einem Passwort steht das Hashingverfahren fest. Es gibt kein Passwort um ein Passwort zu entschlüsseln.
Natürlich könnte man ein Passwort auch mit einem 4096Bit-Key verschlüsseln. Aber um zu prüfen, ob jemand das korrekte Passwort angegeben hat, müsste man das gespeicherte Passwort entschlüsseln und dazu braucht man den Key. Also wenn der Key einmal geleakt ist, bräuchte man nichtmal mehr Passworthashes Bruteforcen, weil dann kann man sie ja direkt entschlüsseln. :d

Nochmal anders ausgedrückt: Ja, ein Passworthash ansich ist der "passwortlose" Crypthographieteil, weil ein Passwort für das man ein Passwort braucht, macht einfach keinen Sinn.
 
Das hängt davon ab mit welchem Algorithmus und wie gehashed wird.
Ja, da geht er nicht mit einer Silbe drauf ein. Stimmt schon.

Müssten die Hashes bzw. "Hashverfahren" ;) aus der Cryptosicht aber nicht mind. so "stark" sein wie die Crypto selbst?
 
Müssten die Hashes bzw. "Hashverfahren" ;) aus der Cryptosicht nicht mind. so "stark" sein wie die Crypto selbst?
Nein.
Wie gesagt, komplett unterschiedliche Einsatzzwecke.
Bei verschlüsselten Daten braucht man den exakten Schlüssel zum entschlüsseln. Andernfalls kommt nur Datensalat raus.

Wenn man ein Passwort knackt, errät man nicht das originale Passwort, sondern man errechnet lediglich irgendeine Zeichenfolge die den selben Hash ergibt (eine Kollision). Mit dieser Zeichenkette kann man sich dann einloggen, aber das exakte Passwort weiß man dadurch auch nicht... aber muss man ja auch nicht.
Wie sicher das ist, hängt eben vom Hashingverfahren und sicher auch der länge der Hashes selbst ab.

Das sind beides komplett verschiedene Sachen, für verschiedene Einsatzzwecke, wobei das eine auch gar nicht für den anderen Einsatzzweck geeignet ist.... in beide Richtungen.
Ein Passwort zu verschlüsseln eignet sich nicht für eine Passwortabfrageprüfung und Nutzdaten zu Hashen bringt auch nix, weil man nie wieder auf die Daten zurückkommt.

Du versuchst hier Äpfel mit Pumpspeicherkraftwerken zu vergleichen.

Funfact nebenbei: Ich habs sogar schonmal erlebt, das zwei komplett verschiedene Digitalfotos (jeweils 8MP) den gleichen MD5-Hash ausgespuckt haben. Also eine Kollision gefunden. Hat man in einem der beiden Bilder nur einen einzigen Pixel minimal geändert, waren die Hashes wieder unterschiedlich.
 
Bei 64 Zeichen erhöht sich die Rechenzeit für Brute-Force mit jeder weiteren Stelle um Faktor 64.
Aber dabei fehlen die Großbuchstaben, also 26 + ÄÖÜ hinzu addieren, dann sind wir bei 93 Zeichen.
Und ein Leerzeichen kann man als weiteres Sonderzeichen ansehen, dann haben wir 94 Zeichen.

Wenn jetzt das Knacken eines 16-stelligen Passworts 3 Monate dauert, dann sind es bei 17 Stellen und 94 Zeichen schon 23,5 Jahre!
Und bei 18 Stellen 2209 Jahre.
Und wenn man dann noch berücksichtigt, das die Rechenleistung jedes Jahr steigt, sollte man nicht mehr mit 16 Zeichen arbeiten, sondern mit mindestens 20 Zeichen.
Dann ist das Passwort theoretisch auch in den nächsten 5-10 Jahren nicht per Brute Force zu knacken.

Oder man nimmt Unicode-Zeichen mit auf, dann reichen auch 10 Stellen.

Was den Hashalgorithmus angeht:
MD5 ist unsicher, ebenso SHA.
Man sollte mindestens SHA256 verwenden.
 
Nein.
Wie gesagt, komplett unterschiedliche Einsatzzwecke.
Das hängt doch unmittelbar zusammen. Wenn du eine verschlüsselte Datei/Container/(whatever) hast, hat der den Hash irgendwo mit onboard. Sonst könnte weder man selbst noch ggf. das Ziel (Empfänger) die Daten nicht entschlüsseln.
Das ist doch sonst wie ne gepanzerte Limo mit 0815 Standardglasscheiben. Da kann man ja auch sagen: Ja gut. Die Scheiben gehören halt nicht zur Karosserie...

@passat3233
Also einfach nicht unter 18 Zeichen gehen...(?) Wobei auch das eigentlich ein alter Hut ist. Schon zu allerersten PGP-Zeiten hat man von "Passphrase" gesprochen. Und das war 1991.

Der ganze Müll mit "sicheren" Passwörtern (sehe xkcd) sieht eher aus wie eine lang angelegte false flag operation.
 
Zuletzt bearbeitet:
Das hängt doch unmittelbar zusammen. Wenn du eine verschlüsselte Datei/Container/(whatever) hast, hat der den Hash irgendwo mit onboard, sonst konnte weder man selbst noch ggf. das Ziel (Empfänger) die Daten nicht entschlüsseln.
Nein. Bei einer verschlüsselten Datei gibts nichtmal einen Hash. Es gibt nur einen Key (ich nenne es jetzt bewusst mal Key, weil das eben kein Passwort ist!) mit dem die Daten verschlüsselt und entschlüsselt werden, bzw. sogar ein Public-Private-Keypair, wobei der public Key nur zum verschlüsseln taugt und nur mit dem private Key entschlüsselt werden kann.
Nirgends in den verschlüsselten Daten taucht so ein Key oder auch nur ein Hash davon auf, man braucht auch gar keinen Hash. Der Key muss auf anderem Wege zum Empfänger gelangen.

Wenn du ein Bild verschlüsselt an jemanden schicken willst, dann verschlüsselst du das (im einfachsten Fall) mit dem Key "1234". Damit der Empfänger es wieder entschlüsseln kann, musst du ihm sagen, das der Key "1234" ist. Beim Entschlüsseln wird nicht geprüft ob der Key "richtig" ist und muss auch gar nicht. Wenn man mit einem falschen Key entschlüsselt, kommt allerdings halt nur Datensalat raus. Also ob der Key falsch war, siehst du daran, das nur Grütze rauskommt. Nicht daran das dir das Entschlüsselungsprogramm sagt, der Key wäre falsch. Das weiß es nämlich selber nicht.

Einfachster Fall: Cäsarianische Verschlüsselung durch Buchstabenverschiebung.
"Hallo" ist zu verschlüsseln. Ich verschiebe alle Buchstaben im Alphabet um 4. 4 ist also der Key.
Verschlüsselt ergibt das dann also: "Lepps", der Key "4" ist in keiner Form in den verschlüsselten Daten enthalten, braucht er auch nicht. Verschiebt man mit dem korrekten Key zurück, kommt wieder "Hallo" raus.
Versuchst du mit z.B. 3 zu entschlüsseln, kommt halt "Ibmmp" raus. Es sagt dir aber niemand, das die 3 als Key falsch war, das erkennst du nur daran, das halt Kauderwelsch rauskommt.
Und das machts zusätzlich schwierig derartige verschlüsselte Daten zu knacken. Du kannst mit beliebigen Keys entschlüsseln, aber ob der Key richtig war, erkennst du nur daran, das sinnvolle Daten rauskommen. Man muss also das Entschlüsselte auch noch darauf prüfen, ob das überhaupt was sinnvolles ist.
 
Zuletzt bearbeitet:
@Liesel Weppen
Bist du jetzt echt wieder bei RSA & Co.? Das macht mich grad müde.

Was ist, wenn man mit RAR/7zip ein Archiv auch gleich mitverschlüsselt?
 
Zuletzt bearbeitet:
Was ist, wenn man mit RAR/7zip ein Archiv auch verschlüsselt?
Keine Ahnung, welchen Verschlüsselungsalgorithmus wendet das denn an? Wenn das Passwort in den verschlüsselten Daten in irgendeiner Form enthalten ist, ist das halt eine sehr schlechte Verschlüsselung. :d
Vermutlich deswegen gilt die Verschlüsselung von Zip auch nicht ansatzweise als sicher. :ROFLMAO:

Evtl. kann aber auch eine beliebige Checksumme irgendwie eingebaut werden, an der man am Ende prüfen kann, ob die entschlüsselten Daten sinnvoll sind. Das ist dann aber trotzdem weder das Passwort, noch ein Hash davon.
 
Zu 7-zip crypto gehören AES und sha256. Die Frage war nur wie das in solchen Fällen funktioniert. Es ist ja nicht viel anders - vom Handling her - wenn es sonst ein VeryCrypt-Container wäre... Wo wir schon bei Zip waren...
 
Was ist, wenn man mit RAR/7zip ein Archiv auch gleich mitverschlüsselt?
Naja was willste denn jetzt wissen? 7zip und dessen Hausformat 7z unterstützt AES256.
Ergo packt 7zip das ganze in ein Archiv -> Passwort wird gehasht (mit Sha256; 2^19mal) der Hash wird wahrscheinlich der Initialisierungsvektor für CBC-Modus von AES sein. Dann wird das Archiv in kleine Schnippsel geteilt und verschlüsselt.
Beim Entpacken gibste das Kennwort ein, sofern der Hashwert stimmt kommt auch das wieder raus was vorher verschlüsselt worden ist.

 
Beim Entpacken gibste das Kennwort ein, sofern der Hashwert stimmt kommt auch das wieder raus was vorher verschlüsselt worden ist.
Die Frage ist, woher 7z weiß, das man ein falsches Passwort eingegeben hat?
Das kann es nur prüfen, wenn der Hash des Passworts mit in dem Archiv steht.
Das kann man natürlich machen, ist dann aber wieder ein zusätzlicher Angriffsvektor, weil man ja "nur" diesen Hash bruteforcen muss. Bietet aber für den Benutzer halt die Bequemlichkeit, das ihm das Programm direkt sagen kann, ob ein eingegebenes Passwort falsch ist (nämlich dann, wenn der Hash nicht passt).

Womit wir aber wieder bei der vorherigen Antwort wären: Wie sicher etwas ist, kommt halt drauf an, wie verschlüsselt wird.

Habe gerademal fcrackzip auf ein Zipfile mit Passwort "1234" laufen lassen. Er findet mögliche Passwörter, muss aber anscheinend das Archiv tatsächlich entpacken um rauszufinden, ob das Passwort korrekt ist.
Das korrekte Passwort zu finden, lediglich mit der Information, das es 4-stellig ist (werden also auch Buchstaben, Sonderzeichen, etc. probiert), hat auf meinem PC 7 Minuten und 51 Sekunden gedauert.
 
Das kann es nur prüfen, wenn der Hash des Passworts mit in dem Archiv steht.
Nö, muss nicht. Kannste auch über ne Checksumme oder ähnliches machen.
Und bevor du nen Sha256-Hash "brute-forct" geht dir entweder die Zeit oder der Speicherplatz aus, sofern du nicht "1234" als Passwort nimmst.

€: oder du machst es über Padding oder per HMAC
 
Nö, muss nicht. Kannste auch über ne Checksumme oder ähnliches machen.
Und bevor du nen Sha256-Hash "brute-forct" geht dir entweder die Zeit oder der Speicherplatz aus, sofern du nicht "1234" als Passwort nimmst.
Ich glaub man kann noch über RNG die Eingabe strecken und Salzen usw. Richtig?

Im Groben war das ja alles soweit bekannt :sneaky: NUR - in dem Kontext eben - worüber handelt dann das verlinkte Artikel? Ob 8 oder 24 Zeichen, wenn die Verfahren die Eingabe eh mir RNGs und so extremen Vermauscheln aufwerten/erweitern?

btw. HMAC
 
Zuletzt bearbeitet:
NUR - in dem Kontext eben - worüber handelt dann das verlinkte Artikel? Ob 8 oder 24 Zeichen, wenn die Verfahren die Eingabe eh mir RNGs und so extremen Vermauscheln aufwerten/erweitern?
Frag den Schreiber des Artikels? Da fehlen halt alle Infos die wichtig wären. Ergo kann dir niemand die Frage beantworten ;)
 
Die Frage reduziert sich nun auf diese, wie wichtig die Benutzereingabe denn ist, wenn bei ordentlich gemachten Verfahren sowieso eine Art "expansion" dessen stattfindet.
 
Zuletzt bearbeitet:
Oooder man setzt einfach auf 2FA, dann kannst du auch ein kürzeres PW verwenden, selbst wenn das kompromitiert wurde. Klappt mit den meisten, wichtigen Diensten und zb auch mit Keepass (TOTP/HOTP). Passende Hardware: Yubikey,Nitrokey.
 
Die Frage reduziert sich nun auf diese, wie wichtig die Benutzereingabe denn ist, wenn bei ordentlich gemachten Verfahren sowieso eine Art "expansion" dessen stattfindet.
Immernoch wichtig ... Rechenleistung steigt jeden Tag ;) Somit verzögern Implementierung wie Key-Stretching zwar den Prozess, schließen aber nicht aus das dein Passwort doch "gefunden" wird.
 
Oooder man setzt einfach auf 2FA, dann kannst du auch ein kürzeres PW verwenden, selbst wenn das kompromitiert wurde. Klappt mit den meisten, wichtigen Diensten und zb auch mit Keepass (TOTP/HOTP). Passende Hardware: Yubikey,Nitrokey.
Ist tatsächlich nicht allgemein verfügbarer Standard :sneaky: Man sollte das also imho schon einmal wirklich verstanden haben, mit der Possworterei, finde ich :whistle: Selbst, wenn man sich nur 3 wirklich wichtige merkt und den Rest eben über z.B. KeePass macht.
 
Ist tatsächlich nicht allgemein verfügbarer Standard :sneaky: Man sollte das also imho schon einmal wirklich verstanden haben, mit der Possworterei, finde ich :whistle: Selbst, wenn man sich nur 3 wirklich wichtige merkt und den Rest eben über z.B. KeePass macht.
Und wozu macht man sich dann Gedanken, wenn fast alle wichtigen Dienste 2FA bereits supporten, inklusive Keepass, und man in Keepass Passwörter beliebiger Länge und Zeichen für jeden Dienst individuell erzeugen lassen kann ? Inklusive Abgleich mit bekannten, geleakten Passwörtern und regelmäßiger Erinnerung, Passwörter zu wechseln ? Ich versteh dein Problem nicht, denn eigentlich gibt es gar keins.
 
Und wozu macht man sich dann Gedanken,
Ist so eine komische Eigenschaft von mir, um Sachen zu verstehen.
Was ich bei dir nicht verstehe ist sich mit Sachen zu beschäftigen von welchen du meinst, daß es da nichts zu verstehen gibt. Bin ich tewa ein Neodymmagnet und du ein Häufchen Späne? Bei allem was dich nicht interessiert: Einfach weitergehen. Optimalerweise wortlos (y)
 
Zuletzt bearbeitet:
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh