Frage zu Mozillas „sicheres Passwort“ und Update

[Raketenlagermeister]

1. Frage:

Kann man irgendwie mit JS feststellen, ob der Benutzer z.B. dem Vorschlag des Mozillas für ein „sicheres Passwort“ gefolgt ist?

2. Die Demo hat ein paar Updates bekommen:

Zuerst einmal wird die „Kompliziertsanforderungen“ des Passwort clientseitig geprüft. Die „Kompliziertsanforderungen“ diskutiere ich nicht, weil diese Geschäftspolitik sind. Im Beispiel ist es: 8 Zeichen lang, Große (A-Z) und kleine (a-z) Buchstaben drin, außerdem Ziffern und „Sonderzeichen“ (Achtung: Umlaute gelten als solche)

Geprüft wird zunächst browserseitig mit den HTML5-Methoden (regulärer Ausdruck). Sind diese nicht verfügbar alternativ mit Javascript.

Auf jeden Fall wird nach der Prüfung der „Kompliziertsanforderungen" die Übereinstimmung mit Javascript geprüft und ggf. der Button, der den Request auslösen soll, bei durchweg positiven Tests aktiviert. (Bei deaktivierten Javascript bleibt der Button aktiv, ggf. greift dann noch HTML5 ein wenn die Anforderungen nicht erfüllt sind.)

Serverseitig wird nach Empfang nochmals geprüft ob die Passwörter kompliziert genug sind und ob diese übereinstimmen. Schließlich weiss niemand ob der Benutzer einen Browser benutzt oder etwas wie wget, curl und co.

Ergänzt habe ich eine Möglichkeit, sich die Inhalte der Passwortfelder für eine konfigurierbare Zeitspanne anzusehen.

Was nach wie vor nicht in dem Skript steht ist die nachfolgende Verwendung des positiv erkannten Passworts. Klar ist, dass hier die password_* Funktionen verwendet werden sollten. Allerdings sollte anno 2021 überlegt werden, ob man noch eine zweite Sicherheitsstufe einbaut (z.B. Versand eines geheimen, zufälligen Bestätigungs-Tokens an eine Telefonnummer (SMS), per Mail oder mit einem anderen Dienst) und Abfrage des Tokens über die Webseite. Das ist aber Geschäftspolitik und nicht Gegenstand meiner Betrachtungen.

Was nach wie vor gilt: Das ist nur Zeug, welches auf meiner „Festplatte“ herumlag. Es funktioniert und genügt als Demo oder Denkansatz - ist aber vom Verwender so umzubauen, dass es zu seinem Projekt passt (z.B. hinsichtlich der Lagerstätte der Voreinstellungen, weiterer Formular-Felder für Benutzername, Telefonnummer, Mailadresse und so weiter).

Im Übrigen verzichte ich auf Tests, ob denn irgendetwas anderes als Text übertragen wurde. Grund: „Wer sowas einträgt kann sich später auch gerne damit anmelden…“. Außerdem sind genug Funktionen (trim!) drin, die für eine „sonstwas zu String“-Konvertierung sorgen und entweder zu einem hartem Fehler oder zu einem leerem Ergebnis und damit zur Ungültigkeit und ergo zum Abbruch führen.

Warum trim()? Manche kopieren das Passwort aus einer Liste. Da könnten Spaces oder Zeilenumbrüche am Anfang oder Ende in die Eingabe geraten.

Die Demo:

https://home.fastix.org/Tests/PWForm/ (Die Dateien mit der Endung '.txt' kann man sich anschauen.)

Testen:

https://home.fastix.org/Tests/PWForm/PWForm.php

Das Hashen käme, wenn der Passwort-Check erfolgreich ist.