Sicherheit bei der Anmeldung an Webanwendungen allgemein - 3 Felder oder 3 Seiten?

Ich seh das eher anders. Und zwar zuvorderst aus Usersicht.
Amazon macht das z.B. bei der CC-Authentifizierung so.
Erste Seite: mTAN eingeben.
Zweite Seite: Passwort eingeben

Das Problem: die zweite Seite sieht fast genauso aus wie die erste. Sogar der Text mit der mTAN steht noch da und auch das Formularfeld ist an der exakt gleichen Stelle. Die vorher eingegebene mTAN ist aber weg. Das sieht auf den ersten Blick nach Fehler im System aus aka TAN wurde nicht übermittelt oder so. Klopft man sie also ein zweites mal ein, schließlich sagt der Text das ja auch so. Wenn da dann die Fehlermeldung kommt, dass die Eingabe nicht korrekt war, schaut man erst doof.
Bis man merkt, dass in dem Formularfeld jetzt in grauer Farbe "Passwort" steht. Es wird aber nicht angegeben, welches Passwort die jetzt genau wollen. Das von Amazon? Das von der CC? Das von der Online-Seite der CC?
Und schwupps kommt die Meldung, dass die CC für Online-Käufe gesperrt ist und man eine andere Zahlform wählen muss.

Da wünsche ich mir schon seit immer, dass da alle Felder auf einer Seite sind. Aber auch andere Seiten haben da unterschiedliche Seiten. Und das ist jedesmal nervig. Da wird jede Eingabe geprüft, was jedes Mal dauert. Somit wird der Einlog-Vorgang unnötig in die Länge gezogen. Und wenns dann noch Probleme mit dem Backbone gibt, kanns sein, dass zwischen den beiden Eingaben die Verbindung abschmiert und sich gar nix mehr tut.

Man muss ja nicht angeben, welche Eingabe jetzt falsch war.

Insgesamt funktionieren mehrere Seiten ja schon, wenn sie denn gut gemacht sind und man auf einen Blick erkennen kann, was denn nun benötigt wird. Solange ein Passwortmanager das mitmacht gibts ja wenig Probleme.
Schwierig wirds dann auch, wenn es für einen Dienst quasi mehrere Passwörter gibt (siehe CC-Gedöns)

Ich mein da eigenständige Passwortmanager, nicht dieses Browserzeugs.
Aber die wird man wohl so schnell nicht mehr los. Sind halt zum einen kostenlos und arbeiten oftmals automatisch.

Schön, dass sich mal jemand Gedanken dazu macht. Ich muss unter Safari jetzt nämlich sowohl den Namen als auch (2. Seite) das PW einzeln per Fingerprint freigeben. Will mich dann noch jemand zu 2FA nötigen, gehe ich die Wände hoch!

Das ist mir schon klar. Ich wollte nur auf die zweimalige Fingerprint-Thematik hinweisen, anschließend noch ne Zertifikatemeldung und dann noch irgendein DSGVO-Dreck, den Du wegdrücken musst – dann ist der Vormittag gelaufen.

PS: Bei mir werden die Cookies bei Neustart gelöscht … das is jedes mal nen Spaß 🤪

imho wäre eine Konfiguration wünschenswert die man an das Sicherheitsbedürfnis anpasst. Im Prinzip wie bei Syno und dem deaktivieren von https. Hilft halt nur nix, wenn dann der Browser brüllt, dass die Seite unsicher ist. Alles maximal nervig mittlerweile und in vielen Fällen einfach sinnfrei.

Aber das hilft Dir für Deine Webanwendung wohl auch nicht weiter 😉

Servus,

der Grund für die mehrseitigen Anmeldeformulare sind schlichtweg unterschiedliche Authentifizierungsmethoden. Und dafür muss der Seitenbetreiber erstmal wissen wer sich anmelden will, um dann die richtige Methode auszuwählen und anzuzeigen. Neben Standard Benutzername/Passwort gibt es mittlerweile verschiedenste Dienste wie z.B. Single Sign On (SSO), Authenticator Apps, Login mit Facebook, Google, Github etc. auch verbreiten sich Passkeys immer weiter. Der Trend geht hin zur passwortlosen Authentisierung. Leider ist das ein schleichender Prozess und darum muss die Abwärtskompatibilität zum Passwort eben z.B. durch mehrseitige Anmeldeformulare sichergestellt werden.

Eine etwas ältere aber immer noch gute Zusammenfassung gibt es auf Twilio.

Es ist also weniger eine Sicherheitsfrage als die schlichte Notwendigkeit eines mehrseitigen Anmeldeprozesses.

Wenn du für deine eigene Webanwendung jedoch nur Benutzername / Passwort anbietest, kannst du auf die vorherige Nutzerverifizierung auch verzichten.

Ich will das Märchen vom Kapuze-tragenden Hacker, der stundenlang unterschiedliche Kombinationen über die Eingabemaske einer Webseite versucht zu knacken, nicht mehr so recht glauben. Passwörter - oder vielmehr deren Hashs - werden auf Serverseite durch Sicherheitslücken Datenbankweise abgezogen, im stillen Kämmerlein geknackt und dann gewinnbringend verkauft. Wer dann Zugriff auf eine Webanwendung haben will, probiert einfach solange Schlüssel aus, bis einer passt. Ob dabei nun der Benutzername, das Passwort oder beides falsch ist, juckt den Angreifer wenig, er nimmt einfach den nächsten Schlüssel aus der Tüte.

Solange die User die Ein-Passwort-Für-Alles-Methode anwenden, haben es Angreifer leicht, da es sich bei den erbeuteten Schlüsseln um Generalschlüssel handelt. Passwortmanager (auch die in den Browser integrierten) helfen genau dieses Problem abzuschwächen indem sie das Nutzerverhalten fördern sich für jeden Dienst ein eigenes Passwort anzulegen.

Stephan

Naja - natürlich kann man den Nutzerkomfort ignorieren. Und sich dann wundern wenn die Anwender eher suboptimale Wege finden... Setze zB. als Vorgabe das "komplexe" Passwörter genutzt werden müssen mit min 10 Zeichen und natürlich nur zufällige Zeichen -> und du wirst auf den Desktops die übliche "password.txt" finden... Daher würde ich das ganze eben auch immer aus der Nutzersicht sehen - wenn du nämlich eben nicht willst das man das eh direkt im Browser oder sonstwo speichert... Ich kenne zB. aus einigen Erfahrungen wo die IT natürlich auch die "password.txt" verboten hat das die Mitarbeiter dann einfach kurz das Passwort im Klartext zB. in Word gemacht haben und dann mitm Handy nen Foto... ob DAS besser ist wenn das Handy mal verloren ist darf man sich selbst überlegen.

Ich fand hierzu den Vortrag Passwords are not going away von Per Thorsheim auf der NDC recht interessant.
Insbesondere auch zur Passwortvergabe, Eingabereihenfolge und MFA.