Hallo,
anlässlich, dass ich mich heute versucht habe, auf der Seite https://hive.vote/ zu registrieren, möchte ich mit euch über Passwort-Richtlinien sprechen, und das Fehlen von solchen auf manchen Websites. Nachdem ich das Problem oft genug hatte, habe ich mir mittlerweile eine Art Binary Search angewöhnt und komme somit relativ schnell zu einem den maximal zugelassenen "Anforderungen" entsprechenden Passwort. Das funktioniert salopp erklärt, indem man die Passwortkomplexität reduziert, falls "geht nicht", und erhöht, falls "geht", aber eben nicht in zufälligen Intervallen, sondern solchen, die erst groß und dann immer kleiner gewählt werden. Optimal halbiert, aber das Suchfeld ist auch eher schwammig definiert.
(Meine gefundenen Settings, die hive.vote gerade so akzeptiert)
Jedenfalls habe ich dann herausgefunden, dass ich so ziemlich jedes normale auf einer westlichen Tastatur vorkommende ASCII-Zeichen verwenden kann, aber die Gesamtlänge 50 Zeichen nicht überschreiten darf. Vollkommen davon abgesehen, dass diese Anforderung nicht da steht, was wohl ganz objektiv einen Designfehler darstellt, fallen mir folgende Punkte zum Thema ein:
Vorneweg: Ich bin definitiv schuldig darin, immer Passwörter mit möglichst hoher Entropie wählen zu wollen, der unbewussten Überzeugung, dass ich damit quasi linear proportional meine Angriffsfläche minimiere. Das ist wohl falsch.
Also erstmal: Natürlich machen Passwörter mit höherer Entropie (Def: https://en.wikipedia.org/wiki/Password_strength#Entropy_as_a_measure_of_password_strength) auch einen besseren Schutz gegen Brute Force. Dabei muss man aber beachten, dass das idR nur gegen Offline-Angriffe hilft, also wenn jemand die Datenbank und/oder die Hashes in die Hand bekommt. Web-Dienste, die nicht gegen Brute Force in der Oberfläche irgendwie schützen, sollten (hoffentlich) komplett ausgestorben sein.
Auf der anderen Seite lassen sich ja DOS-Angriffe über sowas wie Brute Force Protections realisieren, wenn nicht vorsichtig vorgegangen wird, wenn zB aus irgendeinem Grund nicht IP-basiert gesperrt wird, sondern der User wieder ganz. Da ist ein stärkeres Passwort wieder eher zu verteidigen.
Auf der anderen Seite ist ein Brute Force Angriff auf ein gehashtes Passwort schon bei 128 bits vermutlich selbst für Staaten (!) unrealistisch, und welcher Geheimdienst will meine/deine Passwörter für metversand24.de (erfunden) angreifen? Bei Sachen wie Wallet Keys ist nachvollziehbar, dass gute Best Practises auf solche Standards bauen, weil könnte ja irgendwann doch mal wichtig werden plus man vergibt sich nichts. (Quelle: sollte es einige geben, kann man sicher nachrechen mit Rate Hashcat moderner GPU * Anzahl GPUs eines realistischen Angreifers (wähle meinetwegen eine Million wobei das nie vorkommen wird), dann kommt man wohl trotzdem noch unter die 128 in einer Anzahl von Jahren, bevor menschliche Zivilisationen entstanden waren. Ob die ganzen Shopping-Passwörter noch sicher sein müssen in 20+ Jahren, darüber lässt sich wohl mindestens streiten.
Unnötig lange Passwörter vermitteln eindeutig ein falsches Gefühl von Sicherheit. Dein langes Passwort bringt dir nämlich rein gar nichts gegen Angriffe wie unverschlüsselte Daten werden durch einen Server-Angriff mitgelesen (und ich habe keine übertriebenen Hoffungen, dass selbst Firmen in Bereichen, die rel. sicherheitskritisch sein sollten, so sauber arbeiten, dass sowas ausgeschlossen ist) und noch viel witziger eigentlich dein eigener PC wird gehackt und dein Passwort-Manager wird extrahiert. Dagegen würden ja wirklich Offline-Passwörter helfen, da kann man sich schon mal überlegen, ob die erhöhte Sicherheit eines langen, komplett zufälligen Passworts, was zu mehreren Zeitpunkten im Klartext im Speicher des PCs liegt, die Sicherheit so signifikant erhöht, abhängig davon, wie ein realistischer Angriff eben aussähe.
Gegen Phishing bringt das übrigens alles nichts.
Ich verlinke hier noch den Wikipedia-Artikel über "Password policy" (https://en.wikipedia.org/wiki/Password_policy), der eine 2017er Richtlinie der NIST über sichere Passwörter enthält, dann beende ich mein Geschwafel und melde mich ab.
Hello,
on the occasion that I tried to register on https://hive.vote/ today, I would like to talk to you about password policies, and the lack of them on some websites. Having had this problem often enough, I have now got into the habit of using a kind of binary search, which allows me to come up with a password corresponding to the maximum allowed "requirements" relatively quickly. This works by reducing the password complexity if "can't", and increasing it if "can", but not in random intervals, but rather in ones that are first chosen large and then smaller and smaller. Optimally halved, but the search field is also rather spongily defined.
(My found settings that hive.vote just accepts).
Anyway, I then found out that I can use pretty much any normal ASCII character found on a western keyboard, but the total length must not exceed 50 characters. Completely aside from the fact that this requirement isn't there, which is probably objectively a design flaw, here's what comes to mind:
*Ahead: I'm definitely guilty of always wanting to choose passwords with as high entropy as possible, of unconsciously believing that by doing so I'm minimizing my attack surface in quasi-linear proportion. This is probably wrong.
First of all: Of course, passwords with higher entropy (Def: https://en.wikipedia.org/wiki/Password_strength#Entropy_as_a_measure_of_password_strength) also provide better protection against brute force. But you have to keep in mind that this only helps against offline attacks, i.e. when someone gets hold of the database and/or the hashes. Web services that don't protect against brute force in the interface somehow should (hopefully) be completely extinct.
On the other hand, DOS attacks can be realized via something like brute force protections, if not done carefully, e.g. if for some reason not IP-based is blocked, but the user again completely. There a stronger password is again more defensible.
On the other hand, a brute force attack on a hashed password at 128 bits is probably unrealistic even for states (!), and which secret service wants to attack my/your passwords for metversand24.de (invented)? With things like wallet keys it is understandable that good best practices build on such standards, because it could become important at some point plus you don't forgive yourself anything. (Source: if there should be some, you can surely calculate with rate hashcat of modern GPU * number of GPUs of a realistic attacker (choose one million for me, but that will never happen), then you will probably still get under the 128 in a number of years before human civilizations were created. Whether all the shopping passwords will still have to be secure in 20+ years is at least debatable.
Unnecessarily long passwords clearly give a false sense of security. Your long password doesn't help at all against attacks like unencrypted data is read by a server attack (and I don't have exaggerated hopes that even companies in areas that should be relatively security-critical work so cleanly that such a thing is excluded) and even more funny actually your own PC is hacked and your password manager is extracted. Offline passwords would really help against that, you can think about whether the increased security of a long, completely random password, which is in plain text in the memory of the PC at several times, increases the security so significantly, depending on how a realistic attack would look like.
By the way, all this is useless against phishing.
I'll link here to the Wikipedia article on "Password policy" (https://en.wikipedia.org/wiki/Password_policy), which includes a 2017 NIST guideline on strong passwords, then I'll end my rambling and sign off.
