Warum sollten Passwörter bei Kryptografie lang und komplex sein?

[Dalek]

Der wesentliche Unterschied zwischen einem Veracrypt Passwort und z.B. dem Passwort zu irgendeiner Webseite ist, dass ein Angreifer das Veracrypt Passwort offline angreifen würde. Eine Webseite kann einfach limitieren, wie oft man ein Passwort ausprobiert oder den Account sogar ganz sperren. Bei einer Festplatte mit Veracrypt verschlüsselt gibt es nur die Kryptographie, nichts anderes dazwischen was den Angreifer verlangsamen könnte.

Ob da jetzt ein Hash verwendet wird ist egal, am Ende wird ein Angreifer hier Brute-force Passwörter generieren und ausprobieren. Und zwar auch parallel, wenn die Ressourcen dafür vorhanden sind. Ganz wichtig ist hier noch wie lange der Entschlüsselungsvorgang dauert, und da sind üblicherweise Methoden wie beim Passwordhashing die entsprechend langsam sind und nicht so einfach auf GPUs gerechnet werden können.

 

[mchawk777]

Ich meine eher, wenn du nur eine Stelle zur Verfügung hast und nur einen Versuch hast, ist es mit 90% immer noch relativ "Sicher".

Irrelevant - und genau DAS habe ich Dir auch erklärt. 🤷‍♂️

 

[Cicaplast]

Das was meine Aussage auslöste ist großartiger Unsinn. Die Größenordnung bei denen die entsprechenden Professoren den Studenten mit entsprechenden Reaktionen würdigen.
Naja und ich wollte irgendwas schreiben, was mit nicht Verwarnung + Ban einbringt.. ich war versucht.

Sorry, aber irgendwie habe ich den Eindruck das du deine Antworten hier ebenfalls verschlüsselst
Ich weiß zumindest nicht was du mir sagen willst.

Hashes sind keine Verschlüsselung!

Ich weiß, habe ich auch nicht behauptet. Sondern nur, dass der Hash auch mit verschlüsselt wird.

 

[Piktogramm]

Man probiert alle möglichen Passwörter aus um daraus wieder den Hash zu erzeugen.
Und wenn mein gewähltes Passwort gefunden wurde ist dies natürlich auch der selbe Hash der verschlüsselt wurde.
Ich denke nun hab ichs ^^

Ich weiß, habe ich auch nicht behauptet. Sondern nur, dass der Hash auch mit verschlüsselt wird.

An sich beschreibst du irgendwas extrem unvollständig, schreibst dir selbst zu irgendwas verstanden zu haben, wobei das was du schreibst unvollständig ist und selbst unter großzügigen Annahmen zum Auffüllen der Unvollständigkeit ist es falsch.

Kein Hash eines Passworts wird bei Veracrypt erzeugt, gespeichert, verschlüsselt! Welchen Sinn sollte das auch in Bezug auf Sicherheit haben? Mit was (Algorithmus, Secret) sollte ein Hash auch verschlüsselt werden?! Folglich sind alle Überlegungen, was Angreifer mit Hashes anfangen unzutreffend, solang es um VeraCrypt oder vergleichbare Lösungen geht.
Solang du gegenteiliges behauptest oder auch nur denkst, hast du grundlegend nicht verstanden wie das Ganze funktioniert.
Dokumentation gibts hier: https://veracrypt.io/en/Documentation.html

 

[Web-Schecki]

Für die Masse der Anwendungsfälle lässt sich ein Hash auch zurück rechnen.

Keine Ahnung, was das mit Anwendungsfällen zu tun haben sollte. Es hängt schlicht von der Hashfunktion ab. Bei kryptographischen Hashfunktionen ist ein "Zurückrechnen" schwierig, weil solche Hashfunktionen definitionsgemäß Einwegfunktionen sein müssen.
Es gibt dann höchstens in der Praxis noch ein paar Dinge zu beachten, z.B. Sicherheit gegen Rainbow-Tables, für die man Salts verwendet.

 

[Cicaplast]

Kein Hash eines Passworts wird bei Veracrypt erzeugt, gespeichert, verschlüsselt! Welchen Sinn sollte das auch in Bezug auf Sicherheit haben? Mit was (Algorithmus, Secret) sollte ein Hash auch verschlüsselt werden?! Folglich sind alle Überlegungen, was Angreifer mit Hashes anfangen unzutreffend, solang es um VeraCrypt oder vergleichbare Lösungen geht.
Solang du gegenteiliges behauptest oder auch nur denkst, hast du grundlegend nicht verstanden wie das Ganze funktioniert.
Dokumentation gibts hier: https://veracrypt.io/en/Documentation.html

Ok, dann verstehe ich es wohl nicht. Ich sagte ja ich kenne mich damit nicht so gut aus.
Aber wenn kein Hash eines Passworts bei VC erzeugt und gespeichert wird, warum wählt man dann einen Hash-Algoryithmus aus?

 

[gaym0r]

Kein Hash eines Passworts wird bei Veracrypt erzeugt, gespeichert, verschlüsselt!

Selbstverständlich wird es das. Stichwort Key Derivation Algorithm....

Dokumentation gibts hier: https://veracrypt.io/en/Documentation.html

Genau und dort ist das ganze erklärt...

An sich beschreibst du irgendwas extrem unvollständig

Über deine Posts kann man das gleiche sagen, da stehen auch verdammt viele Halbwahrheiten bzw. kompletter technischer Unsinn drin.
Das hier ist zum Beispiel eine sehr wirre Aussage:

Ergo lohnt es sich Passwörter zu probieren anstatt die Hashes.

Erstmal hat niemand impliziert, dass Angreifert direkt mit Hashes versuchen zu entschlüsseln und zweitens kommt der Angreifer aber nicht drum herum, eben genau das zu machen, wenn auch indirekt. Er muss die Hashes der Passwörter berechnen und damit zu versuchen den Header zu entschlüsseln. Das erhöht den Rechenaufwand und somit die benötigte Zeit und ist schlicht notwendig.

Bevor ich also @Cicaplast an den Kopf werfe, dass er irgendwas nicht verstanden hat, würde ich kleine Brötchen backen.

 

[foofoobar]

Ok, dann verstehe ich es wohl nicht. Ich sagte ja ich kenne mich damit nicht so gut aus.
Aber wenn kein Hash eines Passworts bei VC erzeugt und gespeichert wird, warum wählt man dann einen Hash-Algoryithmus aus?

Der Hash wird nicht gespeichert. (Das wäre ziemlich dämlich)

Ansonsten kannst du heute davon ausgehen das alles was einigermaßen ernsthafte Crypto betreibt die Passwörter oder Passphrases hasht.
Und wäre das bei Veracrypt nicht der Fall würden sich Tausende von Menschen dazu berufen fühlen dieses in die Welt zu brüllen.

 

[kieleich]

Bei cryptsetup / LUKS wird ein Hash gespeichert (Digest im luksDump), sonst könnte man nicht sagen, ob das eingegebene Passwort, richtig oder falsch war und der Container würde mit dem falschen Key geöffnet, Ergebnis Daten Salat

Der Hash des Passwort wird nicht gespeichert der Key auch nicht, sondern eine Vermischung von den beiden (Keyslot im luksDump). Ohne das eine, kommt man nicht an das andere.

Der Key an sich ist immer ein reines Zufall Produkt und hat mit dem passwort nicht zu tun, das passwort holt den nur aus der keyslot area heraus

Je sicherer das passwort (je mehr Entropie es hat) ist des to weniger musst du dich darauf verlassen das die Hashfunktion teuer genug ist um das Bruteforce zu verhindern. Mit Passwörter a la XKCD ist das Ding eben auch in 500 Jahren geknackt, weniger wenn du mehr Hardware hinstellst und mehr als 1000 Versuche die Sekunde schaffst.

Hier spielt eine gewisse Paranoia mit wenn dein Gegner ein ganzes Rechenzentrum zur Verfügung hat oder mehrere dann reichen 4 Zufallswörter auch nicht mehr ...

 

[gaym0r]

Bei cryptsetup / LUKS wird ein Hash gespeichert (Digest im luksDump), sonst könnte man nicht sagen, ob das eingegebene Passwort, richtig oder falsch war und der Container würde mit dem falschen Key geöffnet, Ergebnis Daten Salat

Ergänzend: Das ist kein Hash des Passworts sondern des Master-Keys und dient nicht zur Passwortprüfung, sondern Integritätsprüfung.

Der Hash des Passwort wird nicht gespeichert der Key auch nicht, sondern eine Vermischung von den beiden (Keyslot im luksDump). Ohne das eine, kommt man nicht an das andere.

Wäre blöd, wenn der Masterkey nicht gespeichert wäre.

 

[kieleich]

Ergänzend: Das ist kein Hash des Passworts sondern des Master-Keys und dient nicht zur Passwortprüfung, sondern Integritätsprüfung.

Effektiv ist das die Passwortprüfung denn eine andere Instanz die darüber entscheidet gibt es nicht

Sonderfall wäre dann ein korrupter Header für den es kein richtiges Passwort mehr gibt

Somit hast du technisch recht das hier der Key auf Korrektheit geprüft wird und nicht das passwort, aber anschaulich für den Anwender und die Fehlermeldungen des Programms selbst sagen halt alle - falsches Passwort, No Such Key Or Pass Phrase

Denke mal hier im Thread wird zu sehr auf Spitzfindigkeiten herum geritten und die meisten meinen doch halbweg das richtige

 

[gaym0r]

Richtig, für den gemeinen Anwender ist deine Aussage natürlich einfacher zu verstehen. Aber ich denke v.a. bei kryptografischen Systemen sollte man halbwegs korrekt bleiben. Immerhin unterscheidet sich VeraCrypt, Luks und Co. von klassischen Login-Systemen. Eben, weil nicht einfach nur geprüft wird ob der Hash der Eingabe mit dem gespeichertem Hash übereinstimmt.

Hier in dem Thread sind nicht nur Spitzfindigkeiten zu finden, sondern auch schlicht Falschaussagen. ("Verschlüsselung mit SHA", Zurückberechnung von Hashes, Verwendung von Hashes bei Veracrypt...)

 

[Piktogramm]

Ok, dann verstehe ich es wohl nicht. Ich sagte ja ich kenne mich damit nicht so gut aus.
Aber wenn kein Hash eines Passworts bei VC erzeugt und gespeichert wird, warum wählt man dann einen Hash-Algoryithmus aus?

https://veracrypt.io/en/Hash Algorithms.html

For PBKDF2-HMAC, the user-selected hash algorithm is used by the VeraCrypt Random Number Generator as a pseudorandom "mixing" function, and by the header key derivation function (HMAC based on a hash function, as specified in PKCS #5 v2.0) as a pseudorandom function. When creating a new volume, the Random Number Generator generates the master key, secondary key (XTS mode), and salt. For more information, please see the section Random Number Generator and section Header Key Derivation, Salt, and Iteration Count.

Hashing ist Teil von der Schlüsselableitung und wird als Pseudozufallsquelle benötigt. Bei PBKDF2 hast du schlicht die Wahl beim verwendeten Hashing.

Er muss die Hashes der Passwörter berechnen und damit zu versuchen den Header zu entschlüsseln. Das erhöht den Rechenaufwand und somit die benötigte Zeit und ist schlicht notwendig.

Das Ergebnis von "Key Derivation" würde ich immer als Schlüssel bezeichnen und nie als Hash. Die Dokumentation von VeraCrypt trennt da sprachlich ebenso zwischen Key und Hash. Was vom Passwort abgeleitet wird ist immer ein Key, der wird nie gespeichert und nur im Ram gehalten. Einen "reinen" Hash über Passwort(+Salt) gibt es schlicht nicht.
https://veracrypt.io/en/Header Key ... keydata area), which contains the master key


@Cicaplast
Wenn du es verstehen willst, schnapp dir die Dokumentation und Code von Veracrypt, lies Wikipediaartikel und stell gegebenenfalls Fragen.

 

[Enigma]

Dann mal die Frage wie lang sollte denn ein Passwort sein?
Ich meine ist ein langes nicht so komplexes Passwort stärker als ein kurzes komplexes?
Oder anders gefragt welches dieser Passwörter ist stärker?

Du musst anders herum denken. Wie lange brauchst du, um ein Passwort zu erraten?

Jetzt geh mal von 8 Kleinbuchstaben aus. Das sind bei 26 Zeichen ca. 208 827 Millionen Kombinationen. Das hört sich nach viel an, aber ein aktuelles Setup schafft dort 32074 SHA-256 Millionen Hashes pro Sekunde. Sprich dein Passwort wäre im Mittel in rund 3 Sekunden geknackt.

Wenn du Klein-Gross-Zahlen berücksichtigst, sind das bei 8 Stellen auch nur 218 340 105 M Kombinationen und wäre in einer Stunde geknackt. Erst wenn du richtung 12 Stellen gehst, wird es sicherer und braucht mit der Hardware 1600 Jahre.

Jetzt musst du davon ausgehen, dass diese Standard-Hardware nicht so Leistungsfähig ist wie optimierte und dedizierte Hardware von staatlichen Institutionen ist und diese gerne 10.000 bis 100.000 davon haben mit ausgefeilten algorithmischen Tricks, die man nicht open-source bekommt. Meine persönliche Vermutung ist, dass selbst dein 12-Stelliges Passwort statt in 1600 Jahre nicht mal einen Tag brauchen würde.

Was man auch nicht vergessen darf, ist dass verdammt viele Menschen die Grossbuchstaben am Anfang haben, Wörter nutzen und Sonderzeichen eher am Ende sind. Damit knackst du auch 16-Stellige Passwörter wie nichts.

PS: Denkfehler können drin sein - hab ich gerade so runtergeschrieben.

 

[Cicaplast]

Ich denke das Hauptproblem ist auch, dass ich zuerst dachte, es funktioniert bei jeder Verschlüsselung irgendwie gleich. Oder zumindest ähnlich.
Dabei unterscheiden sich wohl Bitlocker, Veracrypt Luks, oder auch Verschlüsselung auf Webseiten massiv von einander.
Meine Ursprungsfrage bezog sich aber primär auf Veracrypt, Luks etc... also Verschlüsselungen womit man Festplatten oder ganze Systeme verschlüsseln kann.
Alles werde ich wohl eh nie verstehen, da das alles viel zu komplex, aber dennoch interessant ist.

 

[Nilson]

Dies betrifft vor allem ja auch die PW-Länge. Wenn ein Angreifer diese wüsste, wäre das ein enormer Vorteil für ihn.
Gehen wir mal davon aus der Angreifer vermutet nur einen Teil des Passwortes. (wie rot markiert)
Weiß aber nicht, wie lang das Passwort ist. Auch nicht, dass nur 2 verschiedene Buchstaben und Zahlen verwendet wurden.

+Qp00!qp999!QP00999+

Um noch mal auf deine Frage zurück zu kommen.
Die Länge des Passwortes zu wissen ist zwar ein Vorteil, aber kein großer. Bei 20 Stellen würde es im gerade mal ~1,4 % sparen, wenn er weiß, dass es ein 20 stelliges Passwort ist

Für den zweiten Fall: Wenn der Angreifer ein Teil des Passworts kennt, wird das effektive Passwort um den Teil kürzer. Dein Passwort wäre als nur noch 15 Zeichen lang anstatt 20.

 

[Cicaplast]

Für den zweiten Fall: Wenn der Angreifer ein Teil des Passworts kennt, wird das effektive Passwort um den Teil kürzer. Dein Passwort wäre als nur noch 15 Zeichen lang anstatt 20.

Ja ok, das verstehe ich schon. Aber in diesem Beispiel geht es ja darum das der Rest des Passworts zum Teil eben auch aus diesen Zeichen besteht. Oder ist dies irrelevant?

Um noch mal auf deine Frage zurück zu kommen.
Die Länge des Passwortes zu wissen ist zwar ein Vorteil, aber kein großer. Bei 20 Stellen würde es im gerade mal ~1,4 % sparen, wenn er weiß, dass es ein 20 stelliges Passwort ist
Anhang anzeigen 1726376

Stimmt, so gesehen ist das noch immer eine enorme Zahl.
Wieviel Hashes schafft heutzutage eine GPU? Ich rechne mal absichtlich mit sehr viel 100.000.000.000.000.000.000 (100 Trillionen)

Die Kombinationsmöglichkeiten habe ich mal abgesenkt zum einfacheren rechnen

100.000.000.000.000.000.000.000.000.000.000.000.000 : 100.000.000.000.000.000.000
=100.000.000.000.000.000.000 / Sekunde

100.000.000.000.000.000.000 : 60= 1666666666666666666 / Minute

1666666666666666666 : 60= 27777777777777780 / Stunde

27777777777777780 : 24= 1157407407407407 / Tage

1157407407407407 : 365= 3.170.979.198.376 / Jahre

Ist das korrekt so?
Kommt mir nicht richtig vor ^^

 

[Nilson]

Stimmt, so gesehen ist das noch immer eine enorme Zahl.

Muss mich leicht korrigieren, muss natürlich auch die 18, 17 ... - stelligen Passwörter abziehen. Macht aber kaum was aus. Zeigt auch wieder wie jedes Zeichen die Sicherheit deutlich erhöht.

Aber in diesem Beispiel geht es ja darum das der Rest des Passworts zum Teil eben auch aus diesen Zeichen besteht. Oder ist dies irrelevant?

Wenn der Angreifer rein zufällig Passwörter rät, wäre es erstmal egal. Relevant ist, das eben noch weitere Zeichen möglich wären.
Aber ein Angreifer wird nicht blind zufällig Passwörter ausprobieren, sondern nach bestimmten Mustern vorgehen, wie z.b. das von @Enigma erwähnte Sonderzeichen am Ende. Wir Menschen sind sehr schlecht darin "echten" Zufall zu erzeugen. Ich würde daher sowohl Passwörter als auch Passphrasen immer mit dem Generator erstellen lassen.

 

[Cicaplast]

Noch mal danke an alle, die sich hier beteiligt haben.
Etwas schlauer ist man ja geworden, obwohl ich nicht alles verstehe.
Macht aber nichts

Bei meiner Rechnung habe ich wohl doch einen Fehler gemacht... waren zwei Nullen zu viel drin

100.000.000.000.000.000.000.000.000.000.000.000.000 : 100.000.000.000.000.000.000
=1.000.000.000.000.000.000 Sekunden
./. 60
=16.666.666.666.666.666 Minuten
./. 60
=277.777.777.777.777 Stunden
./. 24
=11.574.074.074.074 Tage
./. 365
=31.709.791.983 Jahre

Kann die Rechnung jemand bestätigen?
Mir kommt das trotzdem noch extrem Lange vor, obwohl der potenzielle Angreifer die genaue Länge des Passwortes wüsste.

Wenn es stimmen sollte, macht Brute Force ja wirklich überhaupt keinen Sinn. Zumindest ab einer gewissen Passwort-Länge und maximalen Zeichenraum.
Da der Angreifer im Normal-Fall die Länge nicht kennt probiert er einfach bis X-Zeichen aus und hofft, dass ein schwaches Passwort mit kleinen Zeichenraum verwendet wurde?!
Oder wie muss ich mir das vorstellen?

Wir Menschen sind sehr schlecht darin "echten" Zufall zu erzeugen. Ich würde daher sowohl Passwörter als auch Passphrasen immer mit dem Generator erstellen lassen.

Ja, da hast du wohl Recht
Übrigens wirklich nur mit Generator erstellen lassen und nicht mit KI.
Hatte da auch schon was zu gelesen, dass dies auch wieder unsicher ist.

Was ist eigentlich mit diesen Tabellen wo angezeigt wird wie lange es dauern würde ein Passwort zu knacken.
z.B. von hier: https://www.hivesystems.com/blog/are-your-passwords-in-the-green?utm_source=tabletext

Bin da noch nicht ganz hinter, ob dies nur für Online gilt und nicht für Bitlocker, Luks, VC etc.?
Ist ja schon ein Unterschied, da bei VC, Luks, Bitlocker der Angreifer physischen Zugang zur Festplatte, PC etc. hat.

 

[Piktogramm]

Kann die Rechnung jemand bestätigen?
Mir kommt das trotzdem noch extrem Lange vor, obwohl der potenzielle Angreifer die genaue Länge des Passwortes wüsste.

Wenn es stimmen sollte, macht Brute Force ja wirklich überhaupt keinen Sinn. Zumindest ab einer gewissen Passwort-Länge und maximalen Zeichenraum.
Da der Angreifer im Normal-Fall die Länge nicht kennt probiert er einfach bis X-Zeichen aus und hofft, dass ein schwaches Passwort mit kleinen Zeichenraum verwendet wurde?!

https://forum.hashpwn.net/topic/96/hashcat-gpu-benchmarks/2

Angenommen, wir haben irgendwoher Hashes von Passwörtern, wir wollen Passwörter. Dann ist der unsichere md5 Algorithmus mit einer Nvidia 4090 mit 162,7GH/s (Giga Hashes je Sekunde, also 162.700.000.000 Hashes je Sekundes) probierbar.

TrueCrypt TrueCrypt RIPEMD160 + XTS 512 bit ist mit 1891,3kH/s (1.891.300 Hashes je Sekunde) probierbar, also fast sechs Größenordnungen langsamer.


Und beliebig Zeichen durchgehen werden kompetente Angreifer nicht. Typischerweise wird als allererstes eine Liste mit den (normalisierten) 10.000 häufigsten Passwörtern genutzt, samt Modifikation dieser Passwörter mit den häufigsten Abwandlungen.

Normalisierung: In anderen Leaks gab es password, Password, pASSWORD, password123 recht häufig. Normalisiert wird darauf "password"
Abwandlung ist dann ein Regelsatz, der Groß-/Kleinschreibung variert, Leetspeak probiert (p455w0rd) und übliche Sonderzeichen einwirft (P4a55w0rd?!).

Wenn man eine große Datenbank mit gehashten Passwörtern abgegriffen hat, wird damit ein erheblicher Teil an Treffern gelingen. Wobei die Regelsätze zum Generieren der zu testenden Passwörter mitunter sehr kreativ sind.

Vor der KI-Welle, die alles an Ressourcen nutzt was irgendwie verfügbar ist, gab es auf AWS und Vergleichbaren Angebote die Möglichkeit sehr günstig Rechenzeit zu mieten. Das waren dann Jobs, die zu unbestimmter Zeit irgendwann mal liefen. Was weit günstiger war, als sich eigene Hardware hinzustellen oder gar zum Fixpreis zu mieten. Es war also bedingt möglichst zu kleinem Taler die Suchbereiche stark auszuweiten.

Was ist eigentlich mit diesen Tabellen wo angezeigt wird wie lange es dauern würde ein Passwort zu knacken.
z.B. von hier: https://www.hivesystems.com/blog/are-your-passwords-in-the-green?utm_source=tabletext

Bin da noch nicht ganz hinter, ob dies nur für Online gilt und nicht für Bitlocker, Luks, VC etc.?
Ist ja schon ein Unterschied, da bei VC, Luks, Bitlocker der Angreifer physischen Zugang zur Festplatte, PC etc. hat.

Ne, die Annahme ist schon, dass die bcrypt Hashes den Angreifenden vorliegen, damit die GPUs fröhlich versuchen können Kollisionen vom Hash zu finden.