Warum müssen Passwörter lang und komplex sein?

[benneq]

Glaub ich noch immer nicht bis zum Beweis des Gegenteils

Für die IMAP und SMTP Verbindung ist das schon übliche Praxis mittels Challenge-Response, wenn kein SSL vorhanden ist. Aber für die Web Logins wäre mir das auch neu.

 

[Simanova]

Was du meist ist wohl eher die Möglichkeit im Browser oder Mail-Programm, etc abgespeicherte Passwörter wieder auszulesen....

Outlook lässt sich bis einschließlich der aktuellen Version ausschließlich mit HASH-Werten für IMAP und POP3 Konten betreiben.

Ergänzung (28. Juli 2020)

Web Logins wäre mir das auch neu.

Bei GMX und Web.de meinte ich natürlich den Abruf per IMAP/POP3 durch Fremdprogramme.

Dass ein Weblogin über SSL abgesichert ist, und keinen HASH-WERT erlaubt sollte klar sein.
Außer der dortige Admin hat seinen Beruf verfehlt.

 

[0x8100]

https://www.explainxkcd.com/wiki/index.php/936:_Password_Strength

 

[cc_aero]

@benneq , auch nicht ganz oder? Challenge-Response funktioniert ja so, das der Server eine Zeichenkette schickt und der Client sendet einen Hash, generiert aus der (zufälligen) Serverzeichenkette + Passwort ( + Nutzername), etc zurück - also tatsächlich auch nicht einfach den Hash des Passwortes, oder?

@Simanova , Also ich weiß nicht was du für ein Outlook betreibts, aber wenn ich in meinem (2016er) statt dem Passwort einen Hash verwende, funktioniert der Login nicht...

 

[DJKno]

Die beste Methode ist weiterhin die Nutzung einer 2-Faktor-Authentifizierung.
Sicherheit lässt sich leider niemals mit viel Komfort zusammenbringen.

 

[benneq]

Dass ein Weblogin über SSL abgesichert ist, und keinen HASH-WERT erlaubt sollte klar sein.
Außer der dortige Admin hat seinen Beruf verfehlt.

Ich hab gerade mal den Login in der GMX Weboberfläche angeschaut (siehe Anhang). Ich bin mir jetzt nicht mehr so sicher
Da tauchen die Worte "hash" und "salt" in den übermittelten Formulardaten auf. Sind zwar keine Werte hinterlegt, aber vielleicht funktioniert es ja tatsächlich auch über den Web Login

also tatsächlich auch nicht einfach den Hash des Passwortes, oder?

Ja, das ist korrekt. Es wird ein salted Hash auf dem Client generiert. Aber: Dieses Verfahren wird halt üblicherweise bei unverschlüsselten Verbindungen eingesetzt. D.h. ein Angreifer kann relativ einfach das Salt auslesen während es vom Server an den Client übermittelt wird.
Die Alternative wäre, dass der Server für jeden Login ein neues Salt generiert, aber: Dann muss das Passwort im Klartext in der Datenbank gespeichert werden. Also beides nicht sooo geil.

 

[cc_aero]

...Da tauchen die Worte "hash" und "salt" in den übermittelten Formulardaten auf...

Ich denke das sind eher Parameter die der Server dir übermittelt und du bzw. dein Browser beim drücken auf "Login" wieder zurücksenden musst, um sicherzugehen das du das Formular eh richtig aufrufst - quasi als Schutz, damit die Login-Verarbeitung nicht von irgendwo anderes aufgerufen werden kann bzw. der Aufruf gar in ein Pishing-Seite eingebaut werden kann.

Das ist eigentlich auch gängige Praxis und sollte eigentlich nix mitn Passwort-hashen selbst zu tun haben.

 

[benneq]

Ich denke das sind eher Parameter die der Server dir übermittelt und du wieder zurücksenden musst, um sicherzugehen das du das Formular eh richtig aufrufst

Und warum steht dann nichts drin? Als CSRF Schutz kann so ein leeres Feld nicht dienen. Ich hab das Formular ganz regulär über die Webseite abgeschickt.

 

[cc_aero]

@benneq , möglicherweiße ist das Teil einer Funktion, die noch nicht implementiert ist. Zumindest eine Art temporäre "userid" wird mim Formular hidden mitgeschickt - evtl. soll die CSRF-Protection verbessert werden und im Frontend warn's schneller als im Backend

Ich kann mir aber nicht vorstellen, dass damit damit der Login mit dem Passwort-Hash möglich ist.
Macht ja auch keinen Sinn, oder? Da müsste man dann ja beim Passwortcheck den übetragenen Passwort-String sowohl im Klartext als auch gehashed checken. Wo her sollte aber auch der User den Hash bzw. den verwendeten algorithmus kennen?

 

[Hayda Ministral]

Für einen Computer ist dieses Password genauso gut wie password123456. Der hat nämlich keinerlei Bezug zu Wörtern.

Da müsste sich aber doch auch mal was machen lassen. So eine Attacke, bei der bei man einfach ein Wörterbuch zu Hilfe nimmt um dessen Kombinationen als erstes zu testen.

Mein Internet funktioniert gerade nicht so gut, schaust Du mal bitte nach ob schon jemand etwas zu den Stichwörtern "Attacke" und "Wörterbuch" geschrieben hat?

 

[PHuV]

Wir lassen gerade im Exchange einen regelmäßigen Check mit PW Sicherheit laufen, die prüfen, ob gegen eine allgemeine Datenbank PWs gefunden werden, und es sind einige, die so entdeckt werden.

 

[onesworld]

An die Hashes kommt der Angreifer durch Hashlisten in öffentlichen Datenbanken aus gesammelten Leaks

Ich weiß ja nicht, wie andere das so machen, aber Hashes kann man selbst berechnen und damit seine Datenbank füllen. Der Algorithmus ist in der Regel offen. Das Problem ergibt sich durch das Salz.

 

[BeBur]

Aber wie zum Geier soll der Angriff in der Realität ablaufen?

Hier wurde schon viel richtiges gesagt.
Stichworte sind Offline vs. Online Angriffe. Offline heißt hier einfach, dass du unabhängig vom angegriffenen Dienst das Passwort knackst. Indem du Hashes besorgst z.b., das haben hier schon welche ausgeführt.
Aber auch auf WPA2 d.h. auf dein WiFi sind solche Offline Attacken möglich. Ich will darauf hinaus dass es keine gute Idee ist sich darauf zu verlassen, das ein Angreifer ja nur Recht langsam bruteforcen könne.

 

[carnival55]

Ich weiß ja nicht, wie andere das so machen, aber Hashes kann man selbst berechnen und damit seine Datenbank füllen. Der Algorithmus ist in der Regel offen. Das Problem ergibt sich durch das Salz.

Deswegen macht man ja auch keine eigene Crypto (als Serveradmin oder Programmierer).
Wenn ich einfach nur MD5, SHA-irgendwas oder einen anderen Hash-Algo nehme und dann womöglich noch einen zu kurzen Salt und den auch noch mehrfach einsetzte, sagt der Internetkriminelle brav "danke", jagt das mit hashcat (-Link-) durch seine GPU-AWS Instanz (-Link-) und hat in (zu) kurzer Zeit die Passwörter.

Wie mache ich das richtig? So (-Link-) und so (-Link-)
Die wichtigsten Keywords:

• bcrypt (und Verwandte)
• HMAC
• Salt & Pepper

Niemals versuchen Crypto selber zu machen!
Das ist der beste Schutz gegen Brute-Force, Dictonary- und Rainbow-Table Angriffe.

Wie läuft das "in the Wild" ab?
a) Das Script-Kiddie "K3v1n" lässt ein Script laufen, das Login-Masken im Internet findet und probiert dann bekannte Kombinationen von Usernamen und Passwörtern durch. Level 2 wäre die geschickte Kombination und/Substitution von bekannten Passwörtern.
Man sollte meinen, dass das Webservern und Firewalls nicht mal mehr ein Gähnen entlockt und solche Versuche in /dev/null verschwinden, leider ist es trotzdem oft genug erfolgreich (Stichwort IoT-Geräte und Default-Passwörter).

b) der Angreifer hat (durch eine Sicherheitslücke in einer Datenbank) Zugriff auf eine Passwort-Datenbank erhalten, kopiert sich die DB und lässt dann unbehelligt von störenden Firewalls etc. seinen Hashcat auf die Einträge los. Level 2 ist hier, dass er via Phishing gegen bekannte User versucht, schneller an die Passwörter ranzukommen ("Das Amazon Sicherheitsteam hat verdächtige Aktivitäten in Ihrem Account festgestellt, bitte ändern Sie -hier- Ihr Passwort.")

Zum Thema Passwortlänge etc. verlinke ich mal auf meinen Beitrag von vor ein paar Tagen.

 

[Hirtec]

Ich hatte in meinem Beitrag beispielhaft das Passwort "?T67793x" genannt.
z.B der SHA1-Hashwert lautet in dem Fall "1a53cd2ec8335622dc7c0f3a61b06cfacba89133". Viel Spaß beim zurückrechnen...

Naja, es wird ja nicht zurückgerechnet, per Brute-Force wird für jede Zeichenkombination der Hash erstellt und mit dem in der Liste verglichen. SHA1 ist ein relativ schneller Hash-Algorithmus, d.h. man kann pro Recheneinheit viele Hashes berechnen und so relativ schnell das Ergebnis bekommen ( im Gegensatz zu z.B. bcrypt).

Jetzt kommt es natürlich auch auf die Hardware im Hintergrund an, aber mit 8 Zeichen und schwachem Hash bist du heute nicht mehr sicher.

Hier noch ein kleiner Vergleich der Geschwindigkeit.

 

[benneq]

im Gegensatz zu z.B. bcrypt

bcrypt wird ja auch erst so richtig schön langsam, wenn man genügend Rounds laufen lässt und hier nicht den Wert auf 1 setzt. Das lässt sich mit SHA und jedem anderen Hash Algorithmus selbstverständlich auch problemlos machen.
Das Schöne an bcrypt ist aber zusätzlich - mal ganz davon abgesehen, dass der Algorithmus auf Passwörter optimiert wurde -, dass man sich um die ganze Datenhaltung nicht mehr kümmern muss: Ein String, ein Algorithmus, ein (nicht) erfolgreicher Login.
Und dieser eine String ist alles was man braucht, um Passwörter sicher abzulegen. Quasi das Apple Produkt unter den Passwort Hashern - nur dass es kostenlos und Open Source ist.

 

[Snakeeater]

Das Unwissen und die Naivität in diesem Thread ist unerträglich:

https://www.kuketz-blog.de/sicheres-passwort-waehlen-der-zufall-entscheidet/

 

[benneq]

@Snakeeater Dann verlinke doch bitte wenigstens irgendwas, wo sich jemand nicht so ungeschickt mit Technik und Sicherheit versucht auseinanderzusetzen.
Der Text enthält offensichtlich logisch falsche Aussagen, und widerspricht sich inhaltlich selbst - mal ganz abgesehen vom Highlighting teilweise möglichst unwichtiger Wörter, das kann sogar die BILD besser. Sowas ist in einem technischen Artikel inakzeptabel.
Ich will nicht sagen, dass ich das besser kann. Aber ich schreibe schließlich auch keine tausendfach gelesenen Blog Artikel.

 

[carnival55]

Der Text enthält offensichtlich logisch falsche Aussagen, und widerspricht sich inhaltlich selbst

Oops? Mike Kuketz fällt sonst eher nicht daudrch auf "logisch falsche Aussagen" zu publizieren.
Manches ist im Laufe der Jahre vielleicht etwas veraltet, ok. Aber "falsch"? Was genau meinst Du denn?

 

[Snakeeater]

Sich bei einem technischen Artikel auf die Formatierung zu fokusieren sagt doch schon alles über den Inhalt dieses Kommentars aus.