Passwortverschlüsselung: Prüfung auf erste 3 Stelle möglich?

[drac23]

Hi Community,

ich habe eine Expertenfrage zum Thema Passwortverschlüsselung, da ich gerade im Kundenservice-Chat eines Telefondienstleisters im Anschluss an die Mailadresse nach den ersten drei Stellen meines Login-Passworts gefragt worden bin.

Auf meine kritische Nachfrage, ob die Passwörter dort denn im Klartext gespeichert würden, so dass ihm das was bringe, erhielt ich die Antwort, dass das nicht der Fall sei. "Wir geben lediglich nach Vorgabe des Kunden die ersten drei Zeichen zur Prüfung ein und erhalten dann eine Bestätigung, ob diese mit Deinem Passwort übereinstimmen oder nicht."

Jetzt die Frage an Leute, die sich wirklich mit Verschlüsselung bzw. (Salted) Passwort-Hashing auskennen, weil mir das erstmal nicht einleuchtet: Kann es wirklich und datenschutzrechtlich natürlich völlig unbedenklich möglich sein, dass man eine Prüfung auf die ersten 3 Stellen eines Passworts implementiert, ohne gegen best practice zu verstoßen?

Besten Dank vorab für eure Einschätzungen!

 

[NeoExacun]

Bei Erstellung des Passworts können ja die ersten 3 Stellen zusätzlich gehasht und gespeichert werden. Wenn das Passwort ansonsten lang und komplex genug ist, ist das erstmal kein Problem.

 

[kamanu]

Also grundsätzliche widerspricht das dem Sinn eines Passwort-Hashes.
Wenn du nur ein Zeichen änderst (oder weglässt) hast du einen komplett anderen Hash. Da gibt's also nix zu vergleichen.

Beispiel:
"IchBinEinPasswort" in SHA256 (kein guter Passworthash, aber als Beispiel):
7e1a29e823eeed64df5aca3342f4f0742cc1c347f98079983502fa342a0fde8e

"Ich" in SHA256:
ca089bd7b1371e37b52c85c2243a4277f75608a0c4b696bbeccaeb5035909f91

Edit: Die Variante von @NeoExacun klingt technologisch machbar. Aber trotzdem irgendwie fragwürdig.

 

[bookie]

Wenn ich in der Firma für den zentralen Linux-Jumphost mein Passwort ändern soll und es ändern sich nicht genügend Stellen, meckert das System. Es erkennt scheinbar, wenn sich nur 1-2 Stellen ändern.
Ich frage mich auch, wie das gehen soll, da jeder Hash ja koplett anders sein sollte (s. kamanu).
Der Mechanisus würde mich da auch interessieren.

 

[Marco01_809]

Man kann zwar die ersten drei Stellen nochmal separat hashen, aber das bringt nichts. 3 ist einfach zu kurz. Man kann die gesamte Liste von möglichen 3-stelligen Kombinationen in wenigen Sekunden bis Minuten errechnen und hat dann auf einen Schlag alles geknackt.

Dann hat man die ersten 3 Stellen aller Passwörter, was die Sicherheit der vollständigen Hashes massiv reduziert, da man nur noch einen Bruchteil der Zeit zum Bruteforcen braucht. 8-10 stellige Passwörter die eigentlich sicher wären werden dadurch knackbar. Und in dem Bereich dürften sich bestimmt die meisten nicht-generierten Passwörter bewegen.

 

[Sannyboy111985]

Bei Erstellung des Passworts können ja die ersten 3 Stellen zusätzlich gehasht und gespeichert werden. Wenn das Passwort ansonsten lang und komplex genug ist, ist das erstmal kein Problem.

Technisch geht das so, auch mit Salt.

Ich weiß nicht ob ich das gut oder schlecht finde.
Das Positive ist, dass es eine bessere Authentifizierung von dir darstellt, als das klassiche Schema mit Addresse, Name, Geburtsdatum etc, was quasi jeder meiner bekannten Kennt.

Abere es schwächt dein Passwort, da die ersten 3 Stellen sich sehr schnell mittels Brute Force knacken lassen.
An der Stelle wäre ich auf jeden Fall Skeptisch, dass das sauber implementiert wurde.

 

[NeoExacun]

Alle möglichen 3-stelligen Kombinationen mit der Hotline durchzugehen dürfte aber schwieriger sein. Und nur darauf soll das Abzielen. Eine Verifikation über deinen Zugriff auf das Konto.

Und meinen Kommentar zur Auswirkung auf die Stärke des Passworts hast du ja mitzitiert.

 

[Marco01_809]

@NeoExacun Es geht aber darum wie sie die 3 Stellen überhaupt sicher speichern wollen. Das ganze Hashing macht man ja damit die Passwörter sicher bleiben selbst wenn ein Angreifer die Datenbank rausträgt und die Passwörter in Ruhe per bruteforce knacken kann. Diese Anforderung wird durch ihre Verifizierungs-Lösung torpediert.

 

[NeoExacun]

Sie nehmen die drei Stellen und einen Salt und hashen die getrennt. Wo ist das technische Problem dahinter?

 

[Marco01_809]

Siehe Post #5.

 

[NeoExacun]

Das wäre ein Problem, wenn die drei Stellen automatisiert abgefragt würden. Werden sie aber nicht.

 

[Marco01_809]

Ich wiederhole... Die Anforderung ist im Allgemeinen, dass die Passwörter sicher bleiben sollen auch in dem Fall, dass ein Angreifer die gesamte Datenbank rausträgt. Dann hat der Angreifer ja sowohl die Hashes der 3-stelligen Präfixe wie auch die regulären Passwort-Hashes. Diese Anforderung wird durch die 3-Stellen-separat-speichern-Strategie (ob gehasht oder nicht) torpediert.

 

[NeoExacun]

Nicht solange die Passwörter lange genug sind. Wenn das sauber umgesetzt wird, geht keine Tür dadurch auf, die nicht eh schon offen steht.

 

[runagrog]

@NeoExacun Wenn ein Angreifer Zugriff sowohl auf die Hashes der ersten 3 Ziffern sowie die Hashes der kompletten Passwörter hat ist das sehr wohl ein Problem.

Wie @Marco01_809 geschrieben hat, wenn du zB ein Passowrt mit 8 Stellen hast (potentiell sicher):
Angreifer macht brute force auf den Hashes der ersten drei Ziffern -> findet erste 3 Ziffern nach kurzer Zeit heraus. Von ursprünglich 8 unbekannten Stellen sind jetzt nur noch 5 unbekannt, da ist brute force dann uU auch möglich.

Die Frage ist wie lang die Passwörter ursprünglich sein müssen. Wenn die drei extra Stellen bei der Mindestlänge mitbedacht sind, könnte es ok sein.

Ergänzung: Ich fände es problematisch dass zB. die 4 words password method dadurch angreifbarer werden, da das erste Wort ggf. durch die ersten 3 Ziffern erkennbar wird. Dann bleiben nur noch 3 unbekannte Wörter übrig.

 

[drac23]

Wow, richtig viele gute Ansätze, besten Dank euch!

So ich es richtig verstehe, wäre das dann technisch zwar möglich, ohne die komplette Sicherheit direkt kompromittiert zu haben, aber trotzdem sehr fragwürdig und wider best practice, weil man im worst case damit indirekt das Knacken der Passwörter vereinfacht.

Das reicht mir dann soweit als Antwort, um hier nicht das große Fass mit Mail an Datenschutzbeauftragten aufzumachen. Für mich wäre das Thema damit also erledigt.

Die Frage ist wie lang die Passwörter ursprünglich sein müssen. Wenn die drei extra Stellen bei der Mindestlänge mitbedacht sind, könnte es ok sein.

mindestens 11 Zeichen + davon mind. ein Kleinbuchstabe, ein Großbuchstabe, eine Zahl, ein Sonderzeichen

 

[Marco01_809]

Mit minimum 11 Zeichen würde ich sagen ist das weitgehend unproblematisch, bruteforce muss dann immernoch 8 Stellen knacken. Scheinbar haben die sich bei der Implementation die richtigen Gedanken gemacht.

Es ist nur trotzdem etwas komisch dass die halt am Telefon nach einem Teil des Passworts fragen, weil man sonst immer eingebläut bekommt "Echte Support-Mitarbeiter werden Sie niemals nach ihrem Passwort fragen." - Wenn dann ein Betrüger kommt und Kunden nach ihrem kompletten Passwort fragt würde das noch weniger Leute wundern.

 

[KitKat::new()]

Mit minimum 11 Zeichen würde ich sagen ist das weitgehend unproblematisch, bruteforce muss dann immernoch 8 Stellen knacken. Scheinbar haben die sich bei der Implementation die richtigen Gedanken gemacht.

That’s according to a recent study from Hive Systems, a cybersecurity company based in Richmond, Virginia, which breaks down just how long it would likely take the average hacker to crack the passwords safeguarding your most important online accounts.

The findings suggest that even an eight-character password — with a healthy mix of numbers, uppercase letters, lowercase letters and symbols — can be cracked within eight hours by the average hacker. Anything shorter or less complex could be cracked instantly, or within a few minutes, by any hacker who knows what they’re doing, even if they’re only using fairly basic equipment.

https://www.cnbc.com/2022/03/20/stu...-less-than-8-characters-long-change-them.html

8 Zeichen sind heutzutage zu wenig

 

[Iqra]

Keine Ahnung was die machen, ich würde für die Anforderung die ersten drei Zeichen als salt für eine bekannte oder errechenbare Zeichenfolge verwenden und hätte dann zumindest Ok für die Entschlüsselung der internen Prüfzeichenfolge.

Aber ja, diese Daten müßten dann schon assoziiert, aber isoliert gespeichert werden wo sonst keine Verbindung zum prod System vorhanden ist.