BE > Passworteinstellungen > Passwort bestätigen, Eingabefeld fehlt?

[3dr]

Mich machte gerade ein Backend-Benutzer darauf aufmerksam, dass ihm -und mir als Admin- in der Version 4.13.6 das Eingabefeld zur Bestätigung eines geänderten Passworts fehlt. In der Version 4.9.31 ist dieses Eingabefeld bei mir noch vorhanden. Meine Suche mit

contao 4 backend password confirmation field

brachte kein Ergebnis, in den Changelogs auf GitHub konnte ich auch nichts finden. Habe ich da etwas übersehen oder ist das jetzt so gewollt? Danke für eure Aufklärung!

[planepix]

Hallo 3dr,
das ist neu in 4.13.
Ist auch beim Aufruf des Installtools so.

Ticket bzw. Changelog habe ich auf die Schnelle nicht gefunden…

[3dr]

Hi planepix, danke für deine schnelle Antwort; verstanden, aber was ist hier der Mehrwert? Mein Benutzer hat ein neues Passwort setzen wollen und sich dieses versehentlich falsch gemerkt, da er es zur Verifizierung ja auch nicht ein zweites Mal eingeben musste. Folglich konnte er sich nicht mehr einloggen und musste mich als Administrator bitten, ihm ein neues vorläufiges Passwort zu setzen. Für mich verständlicherweise kritisierte er dieses Verhalten mit der Bemerkung:

Das geht in anderen Systemen aber durch das Passwort-bestätigen-Feld deutlich besser.

Für ihn war es der erste Kontakt mit Contao als CMS und die erste Handlung nach dem Login Warum ist das jetzt so und kann man das ändern? Danke euch!

[Spooky]

https://github.com/contao/contao/pull/3052
https://uxmovement.com/forms/why-the...ield-must-die/

[lucina]

Möglicherweise wäre die bessere Idee, beim Setzen eines Passwortes die Eingabe nicht zu maskieren. Aber das zieht dann natürlich wieder neugierige Schulterblicke nach sich.

Ich bin auch nicht sicher, ob ein Artikel über bessere Conversionrates den skizzierten Fall so abbildet.

[3dr]

Hi Spooky, zunächst vielen Dank für deine Links und dir und allen Anderen, die permanent an einer Verbesserung von Contao arbeiten!

Wie im verlinkten Artikel beschrieben, sollte jedoch unbedingt mit dem Entfernen des Passwort-Bestätigen-Felds eine Möglichkeit eingebunden werden die es erlaubt, das gesetzte Passwort vor dem Speichern zu prüfen:

It’s not enough to exclude the confirm password field. Many sites exclude it, but don’t offer an unmasking option. If users mistype their password, the masking will keep users from recognizing it. This leads to failed logins, password resets and user frustration. You should include an option for users to unmask their password input. This allows them to check what they typed to prevent any errors. Knowing they typed in the correct password can comfort them before they submit the form.

Dieser Schalter funktioniert allerdings im Backend von Contao aktuell nicht und fehlt auch im Formular das dem Benutzer angezeigt wird wenn er bei erster Anmeldung ein neues Passwort zu setzen hat. Das führt nicht nur zu:

failed logins, password resets and user frustration

sondern bedeutet auch zusätzlichen Aufwand für Administratoren und ist Kunden schwer zu vermitteln - oder habe ich hier noch etwas völlig falsch verstanden?

Besteht die Möglichkeit über einen Eintrag in einer Konfiguration-Datei das Passwort-Bestätigen-Feld so lange wieder herzustellen, bis es möglich ist sich über einen Schalter das neu gesetzte Passwort vor dem Speichern anzeigen zu lassen?

[3dr]

Ich bin auch nicht sicher, ob ein Artikel über bessere Conversionrates den skizzierten Fall so abbildet.

Also ich bin mir sicher, dass ich keine hohen Conversionrates für Passwortänderungen brauche Das war falsch, ich will ja gerade dass die Conversion des Passworts funktioniert.

[Spooky]

Dieser Schalter funktioniert allerdings im Backend von Contao aktuell nicht und fehlt auch im Formular das dem Benutzer angezeigt wird wenn er bei erster Anmeldung ein neues Passwort zu setzen hat.

Melde das jeweils als eigene Bug-Reports.

[3dr]

Melde das jeweils als eigene Bug-Reports.

erledigt.

[tab]

Also ich bin mir nicht sicher, wer diese "Studien" durchführt. Jedenfalls werden diejenigen festgestellt haben, dass die "Conversion" noch weit mehr sinkt, wenn die eingegebenen Passwörter nicht funktionieren, weil man sich vertippt hat oder die Shift-Taste versehentlich aktiv war - und man keine Möglichkeit hatte, dies bei der Eingabe festzustellen. Zum selben Schluss sind ja wohl auch die Autoren des verlinkten Artikels gekommen.

Das Argument mit dem unbeaufsichtigten Liegenlassen des Geräts zieht m.E. überhaupt nicht. Natürlich sollte das sichtbar machen des eingegebenen Passworts nur solange funktionieren, bis das Passwortformular abgeschickt ist. Es soll ja lediglich die Kontrolle des eingegebenen Passworts ermöglichen, bevor es gespeichert wird. Wer sein Gerät während der Passworteingabe - oder überhaupt unbeaufsichtigt ohne Sperre - rumliegen lässt, der hat entweder bereits die Kontrolle über sein Leben verloren oder wird sie sehr bald verlieren. Ebenso der mögliche "Schulterblick" beim sichtbar machen des Passworts. Denn mein persönlicher Workaround ermöglicht das noch viel besser. Ich schreibe das vorgesehene Passwort dann z.B. in Notepad++ und füge es mit Copy&Paste ins Passwortfeld ein. So weiss ich wenigstens, was ich eingegeben habe und ob das dem entspricht, was ich eingeben wollte. Wenn man irgendwo ein Passwort eingeben muss und nicht kontrollieren kann, was man eingegeben hat, dann wünsche ich mir zuallermindest zwingend eine funktionierende "Passwort vergessen" Funktion. Alles, was unnötig das häufigere Eingreifen des Admins erfordert ist abgrundtief böse . Es kann nicht die Aufgabe des Admins sein, versehentlich falsch eingegebene Passwörter zurückzusetzen. Es reicht völlig, wenn er die vergessenen Passwörter zurücksetzen muss.

Dass im Backend die Anzeige des aktuell bereits gesetzten Passworts nicht möglich ist, ist gut und richtig. An der entsprechenden Stelle kann man ja als Benutzer problemlos ein neues Passwort eingeben ohne das alte zu kennen, (Was noch ok ist, weil man das ja sowieso beim Anmelden eingegeben haben muss, um an diese Stelle zu kommen) und als Admin im Notfall das Setzen eines neuen Passworts durch den Benutzer erzwingen und es damit dem Benutzer ermöglichen kann, ein neues Passwort zu setzen ohne bereits angemeldet zu sein. Ob es allerdings im Sinne des Erfinders ist, dass jeder, der den Benutzernamen kennt oder errät, dann ein neues Passwort setzen kann? Ohne aktive 2FA sollte so etwas m.E. nicht möglich sein. Dann muss der Admin zwingend ein neues Passwort setzen können. Was er ja letztlich auch kann, wenn er auf die Idee kommt, sich selbst als der fragliche Benutzer anzumelden und in der Login-Maske ein neues Passwort zu setzen. Wirklich optimal ist das aber auch nicht, es bleibt trotzdem eine (hoffentlich dann kürzere) Zeitspanne, in der praktisch jeder den Benutzeraccount übernehmen kann.

[Spooky]

erledigt.

Du hast nur reported, dass das Passwort von bereits angelegten Mitgliedern und Benutzern nicht angezeigt werden kann - was auch korrekt so ist (und auch technisch ansonsten nicht möglich wäre, da das Passwort natürlich verschlüsselt gespeichert wird).

Du hast jedoch geschrieben, dass die Passwort-Anzeige bei der neuen Vergabe nicht funktioniert. Dazu hast du jedoch noch keinen Bug-Report angelegt (falls dieser Fehler denn tatsächlich überhaupt besteht).

// edit: ah hier ist es eh: https://github.com/contao/contao/issues/5128

[Spooky]

Jedenfalls werden diejenigen festgestellt haben, dass die "Conversion" noch weit mehr sinkt, wenn die eingegebenen Passwörter nicht funktionieren, weil man sich vertippt hat oder die Shift-Taste versehentlich aktiv war - und man keine Möglichkeit hatte, dies bei der Eingabe festzustellen.

Warum sollte dadurch die Conversion sinken? Das Passwort oder E-Mail Adressen zewi mal eingeben zu müssen ist unnötig und lästig. Je geringer die Hürde desto besser.

[tab]

Dass im Backend die Anzeige des aktuell bereits gesetzten Passworts nicht möglich ist, ist gut und richtig. An der entsprechenden Stelle kann man ja als Benutzer problemlos ein neues Passwort eingeben ohne das alte zu kennen, (Was noch ok ist, weil man das ja sowieso beim Anmelden eingegeben haben muss, um an diese Stelle zu kommen)

Das nehme ich zurück und behaupte das Gegenteil . Wie auch @Spooky mittlerweile geschrieben hat, muss man hier aber zwischen bestehenden, bereits gespeicherten und der neuen Vergabe unterscheiden. Bei der Neuvergabe wäre es natürlich schon sinnvoll, das Passwort kontrollieren zu können. Ausloggen und versuchen sich wieder einzuloggen reicht offensichtlich nicht für die Kontrolle.

[tab]

Warum sollte dadurch die Conversion sinken? Das Passwort oder E-Mail Adressen zewi mal eingeben zu müssen ist unnötig und lästig. Je geringer die Hürde desto besser.

Bezüglich des Passwort-Bestätigungsfelds hast du und die Studie vermutlich recht. Aber eben nur, wenn man dann die (einfache!) Kontrolle der Eingabe auf andere Weise ermöglicht. Ansonsten führt halt jede Fehleingabe entweder zur Frustration oder zu Mehrarbeit für den Admin. User mögen keine komplizierten Formulare und Admins keine unnötige Arbeit. Das führt sonst halt am Ende zum Verlust des Users, bzw zum Abbruch der Registrierung oder zur Nichtbenutzung des Kontos wegen nicht funktionierendem Passwort. Irgendwann eventuell auch zum Verlust des Admins. Außer man überzeugt ihn mit mehr Geld.

[3dr]

Ich schreibe das vorgesehene Passwort dann z.B. in Notepad++ und füge es mit Copy&Paste ins Passwortfeld ein.

Ja, logisch, mache ich natürlich auch so, das darf man aber nicht einer*m Redakteur*in zumuten, die zeigen mir einen Vogel und wollen Wordpress :-|

Alles, was unnötig das häufigere Eingreifen des Admins erfordert ist abgrundtief böse . Es kann nicht die Aufgabe des Admins sein, versehentlich falsch eingegebene Passwörter zurückzusetzen. Es reicht völlig, wenn er die vergessenen Passwörter zurücksetzen muss.

Sehe ich auch so, das ist jetzt aber durch die Änderungen in Contao 4.13 so gesetzt und es sieht aktuell auch nicht so aus, dass sich da was ändert, siehe: GitHub

[Spooky]

Das was fehlt ist eine Passwort zurück setzen Funktion für Backend User.

[3dr]

Das was fehlt ist eine Passwort zurück setzen Funktion für Backend User.

Stimmt, darum geht es wohl letztendlich. Ich möchte an dieser Stelle aber auch etwas zurückrudern; die aktuelle Funktionalität erlaubt es, sich vor dem Speichern das neu eingegebene Passwort nochmals über den Toggler anzeigen zu lassen, eine Möglichkeit der Überprüfung ist damit also vorhanden. Was korrekterweise nicht funktioniert, ist die Möglichkeit sich ein bereits gespeichertes Passwort mit dem Toggler nochmals anzeigen zu lassen; auch das ist korrekt so. Auf GitHub wurde vorgeschlagen den Toggler zur Anzeige gespeicherter Passwörter auszublenden, da er ja nur Asterikse anzeigen kann, ich finde das sinnvoll.