jQuery 2 Eingabefelder vergleichen

[Rainer]

Hallo,

wie kann man 2 Eingabefelder mit jQuery "Live" vergleichen? Gibt es da eine spez. Funktion dafür oder ein Tutorial?

<input type="password" id="Pass" pattern=".{8,}" name="Pass" value="" required>
<br>
<input type="password" id="Pass2" pattern=".{8,}" name="Pass2" value="" required>

Gruß Rainer

[1unitedpower]

<input type="password" id="Pass" pattern=".{8,}" name="Pass" value="" required>
<br>
<input type="password" id="Pass2" pattern=".{8,}" name="Pass2" value="" required>

Passwort-Felder sind schlecht für die Usability^[1].

Passwort-Bestätigungs-Felder sind noch schlechter^[2].

Es gibt Alternativen^[3].

---

1. http://alistapart.com/article/the-problem-with-passwords, https://www.nngroup.com/articles/stop-password-masking/ ↩︎

2. http://uxmovement.com/forms/why-the-confirm-password-field-must-die/ ↩︎

3. https://www.viget.com/articles/password-fields-are-annoying ↩︎

[Rainer]

Passwort-Felder sind schlecht für die Usability[^1].

Passwort-Bestätigungs-Felder sind noch schlechter[^2].

Dann mach ich eben <input type="text"> draus. Es beantwortet allerdings nicht im entferntesten meine Frage.

[Gunnar Bittersmann]

@@Rainer

Es beantwortet allerdings nicht im entferntesten meine Frage.

Dafür macht es etwas viel besseres: Es zeigt dir, welche Frage du zuerst stellen solltest. Nicht die nach dem Wie, sondern die nach dem Ob. Und dem Warum.

Müssen Nutzer bei der Registrierung (bzw. beim Passwort-Ändern) damit genervt werden, ihr Passwort zweimal einzugeben?

Die Antwort ist: Nein, müssen sie nicht. Denn

1. Nutzer haben durch die Passwort-anzeigen-Funktion (die vorhanden sein sollte!) die Möglichkeit zu erkennen, ob das was sie eingeben dem entspricht, was sie eingeben wollten.

2. Sollten sie sich nach der Registrierung nicht einloggen können, weil das Passwort nicht übereinstimmt, können sie sich über die Passwort-vergessen-Funktion (die vorhanden sein muss!) ein neues Passwort setzen.

Passwort-wiederholen-Felder sind keine Notwendigkeit, sondern schlechtes Design.

LLAP 🖖

[Gunnar Bittersmann]

@@Gunnar Bittersmann

die Passwort-vergessen-Funktion (die vorhanden sein muss!)

… und die besser „Passwort ändern“ heißen sollte.

„Vergessen“ klingt vorwurfsvoll. Als ob der Nutzer Schuld ist, dass er sein Passwort vergessen hat. Das Problem ist vielmehr, dass es überhaupt notwendig ist, dass sich Nutzer Passwörter merken müssen.

„Ändern“ macht dem Nutzer keinen Vorwurf, es benennt keinen „Fehler“, sondern die Aktion, die der Nutzer ausführen möchte.

LLAP 🖖

[Matthias Apsel]

Hallo Gunnar Bittersmann,

… und die besser „Passwort ändern“ heißen sollte.

„Passwort zurücksetzen“ trifft es auch ganz gut. Ebenso wie „erneuern“.

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Matthias Apsel

… und die besser „Passwort ändern“ heißen sollte.

„Passwort zurücksetzen“ trifft es auch ganz gut.

Das hatte ich erst sogar in meiner Antwort drin, hab es aber rausgenommen, weil es was anderes ist.

Bei „Passwort zurücksetzen“ generiert das System ein Passwort, mit dem sich der Nutzer erst einloggen muss, um es gleich darauf nochmals zu ändern. Ein unnötiger Schritt. Warum soll der Nutzer nicht gleich sein Passwort ändern können?

Ebenso wie „erneuern“.

Da würde ich „neues Passwort erstellen“ in die Runde werfen. Wenngleich das auch bedeuten könnte, dass das System das Passwort erstellt, nicht der Nutzer.

LLAP 🖖

[woodfighter]

Tach,

http://alistapart.com/article/the-problem-with-passwords

der Artikel spricht davon, Passwörter zu verschlüsseln, das ist fundamental falsch, es wird behauptet, dass ein Passwort-Reset-Mechanismus die Sicherheit verringert, was ich anzweifeln würde und mich würden die zugrundeliegenden Zahlen interessieren, die im ursprünglichen Nielsen-Artikel

https://www.nngroup.com/articles/stop-password-masking/

zur Aussage „The more uncertain users feel about typing passwords, the more likely they are to (a) employ overly simple passwords and/or (b) copy-paste passwords from a file on their computer. Both behaviors lead to a true loss of security.“ geführt haben (mal davon abgesehen, dass beide Folgerungen, nicht unbedingt ein Problem darstellen(das hängt stark von der Einschätzung der Wichtigkeit der Sicherheit für genau diese Seite ab)).

http://uxmovement.com/forms/why-the-confirm-password-field-must-die/

Da bezieht man sich auf die Studie http://www.formisimo.com/blog/case-study-small-changes-lead-to-a-55-increase-in-conversions/, in der die vorhandenen Zahlen nicht ganz unproblematisch interpretiert werden:

14.3% more visitors starting the form after visiting the page

Ja, aber das sind nur 5% der Gesamtbesucher (gleichzeitig enthält der zweite Untersuchungszeitraum 33% mehr Besucher als der erste und ich bin mir nicht sicher, ob man dann mit den vorhandenen Zahlen schon außerhalb der Varianz liegt).

A 56.3% increase in overall conversions

Das sind immerhin fast 9% der Gesamtbesucher (Prozentangaben von kleinen Differenzen bei kleinen Absolut-Prozenten wirken immer wieder großartig).

A 23.9% decrease in the number of corrections made in the form

Diese Zahl könnte interessant sein, wenn man gleichzeitig wüßte, wie viele User sich mit dem vergebenen Passwort tatsächlich eingeloggt haben (vielleicht haben diejenigen, die früher korrigieren mussten, nämlich dann aufgegeben und keinen Reset angefordert (halte ich für unwahrscheinlich, aber die Zahlen geben es leider nicht her)).

Was allen Artikeln fehlt ist die Aussage, dass das Abspeichern mancher Passwörter ein Sicherheitsgewinn sein kann: Eines der größten Probleme ist nämlich die Wiederbenutzung von Passwörtern (d.h. wenn mein Passwort für irgendein obskures Forum das selbe ist, wie für meine Bank und ersteres in die falschen Hände fällt (weil nicht verschlüsselt übertragen oder unsicher gespeichert), habe ich ein Problem). Ich habe gerade nachgesehen, ich habe im vergangenen Jahr alleine 22 Passworte aus meinem Passwortcache im Browser auf diesem Rechner verwendet (das ist nur ein Bruchteil der dort vorhandenen Passworte), darunter obskure, die ich ziemlich sicher nicht häufiger als einmal im Jahr brauche (z.B. Krankenkasse und Energieversorger); diese kann ich mir nicht merken, wenn sie alle ausreichend sicher und unterschiedlich sind. Stattdessen muss ich mir nur drei Passwörter merken: FDE, Rechner-Login und Passwortcache; damit kann ich bei den gespeicherten Passwörtern die Sicherheit erhöhen, indem ich tatsächlich zufällige und ausreichend lange Passwörter verwende. Es gibt Passworte, die vermutlich nicht in den Passwortcache gehören (z.B. Banken) und man muss darauf achten, dass dieser ausreichende Sicherheitsmaßnahmen vorsieht (z.B. Ablegen der Passworte nur in verschlüsselter Form), aber bei den heutigen Anforderungen an sichere Passworte ist alles andere eher unmöglich.

mfg
Woodfighter

[1unitedpower]

http://alistapart.com/article/the-problem-with-passwords

der Artikel spricht davon, Passwörter zu verschlüsseln, das ist fundamental falsch […]

Ob Verschlüsselung notwendig ist, hängt ganz vom Anwendungsfall ab. Bei der Übertragung von Passwörtern oder der dauerhaften Speicherung in Passwort-Managern ist Verschlüsselung ratsam. Bei der Authentifizierungsstelle hingegen ist es ratsam das Passwort mit einem Einweg-Verfahren, das nicht zurückgerechnet werden kann, zu speichern. Die Ausssage des Artikels verliert ihre Gültigkeit aber auch nicht, wenn du "encrypted" mit "hashed" ersetzt.

http://uxmovement.com/forms/why-the-confirm-password-field-must-die/

Da bezieht man sich auf die Studie http://www.formisimo.com/blog/case-study-small-changes-lead-to-a-55-increase-in-conversions/, in der die vorhandenen Zahlen nicht ganz unproblematisch interpretiert werden:

Wie kommst du darauf? Auf mich macht die Auswertung den Eindruck einer seriösen statistischen Analyse. Dafür sprechen die folgenden Punkte:

• Die Stichproben-Ergebnisse sind transparent offengelegt.
• Eventuelle andere Einflussgrößen werden benannt.
• Es werden unterschiedliche statistische Kenngrößen berechnet.
• Die Resultate werden nicht mit einer einzigen sondern mit verschiedenen Darstellungen untermauert.

Außerdem finde ich, dass deine Berechnungen die gleiche Sprache sprechen. Du erhälst betragsmäßig kleinere Zahlen, weil du dich jeweils auf den Gesamtstichprobenumfang beziehst. Aber auch diese Zahlen bestätigen im Grunde die selben Zusammenhänge.

14.3% more visitors starting the form after visiting the page

Ja, aber das sind nur 5% der Gesamtbesucher (gleichzeitig enthält der zweite Untersuchungszeitraum 33% mehr Besucher als der erste und ich bin mir nicht sicher, ob man dann mit den vorhandenen Zahlen schon außerhalb der Varianz liegt).

Du meinst vermutlich die statistische Signifikanz. Ich weiß nicht, was man im UI-Bereich typischerweise als Signifikanz-Niveau ansetzt, aber 5% bzw. 14.3% sind rein intuitiv nicht mehr zufällig. Es macht allerdings auch wenig Sinn im Nachhinein ein Signifikanz-Niveau festzulegen, weil man eben nicht mehr unbefangen ist. Das könnte man der Auswertung in der Tat negativ anlasten.

[woodfighter]

Tach,

Ob Verschlüsselung notwendig ist, hängt ganz vom Anwendungsfall ab. Bei der Übertragung von Passwörtern oder der dauerhaften Speicherung in Passwort-Managern ist Verschlüsselung ratsam. Bei der Authentifizierungsstelle hingegen ist es ratsam das Passwort mit einem Einweg-Verfahren, das nicht zurückgerechnet werden kann, zu speichern. Die Ausssage des Artikels verliert ihre Gültigkeit aber auch nicht, wenn du "encrypted" mit "hashed" ersetzt.

du hast recht, ich habe hier zu streng reagiert, weil ich das Wort Verschlüsselung nicht gerne in der Nähe von Passwort sehe (außer in bereits genannten Zusammenhängen). Allgemein sollte fast niemand über die Verschlüsselung von Passworten nachdenken, da man auf dem Transportweg eh alle Daten verschlüsseln sollte und Passwortcache-Entwicklung eher ein Nischenmarkt ist.

Außerdem finde ich, dass deine Berechnungen die gleiche Sprache sprechen. Du erhälst betragsmäßig kleinere Zahlen, weil du dich jeweils auf den Gesamtstichprobenumfang beziehst. Aber auch diese Zahlen bestätigen im Grunde die selben Zusammenhänge.

Für die Interpretation durch den Leser macht die absolute Größe aber einen Unterschied aus; eine Grafik wie http://labs.davidbauer.ch/fify.html ist im Prinzip nicht nötig, die Achsen sind ja eindeutig beschriftet, aber solange man sich die Zahlen nicht ganz so exakt ansieht, ist die Wirkung eine deutlich andere.

14.3% more visitors starting the form after visiting the page

Ja, aber das sind nur 5% der Gesamtbesucher (gleichzeitig enthält der zweite Untersuchungszeitraum 33% mehr Besucher als der erste und ich bin mir nicht sicher, ob man dann mit den vorhandenen Zahlen schon außerhalb der Varianz liegt).

Du meinst vermutlich die statistische Signifikanz.

Ja, ob der Unterschied signifikant ist, kann man nicht entscheiden, ohne zu wissen, wie die Varianz ist oder bringe ich jetzt meine Stochastik durcheinander?

Ich weiß nicht, was man im UI-Bereich typischerweise als Signifikanz-Niveau ansetzt, aber 5% bzw. 14.3% sind rein intuitiv nicht mehr zufällig.

Und ich würde intuitiv das Gegenteil behaupten, aber wie gesagt, ich habe keine Ahnung, wie die Zahlen in anderen Monaten waren und wie viel das allgemein variiert. Wenn immer noch 39% der User nach dem Beginn des Ausfüllens, des Formulars wieder damit aufhören, würde es mich zumindest nicht wundern, wenn der Wert insgesamt stark variiert.

mfg
Woodfighter

[1unitedpower]

wie kann man 2 Eingabefelder mit jQuery "Live" vergleichen? Gibt es da eine spez. Funktion dafür oder ein Tutorial?

Zerlege das Problem in seine einzelnen Bestandteile. Zunächst solltest du eine klare Vorstellung davon gewinnen, was "Live" in diesem Zusammenhang bedeutet. Die Anführungszeichen deuten darauf hin, dass hier Unkarheit besteht. Bei Eingabefeldern ist eine praktische Antwort darauf: wenn sich der Wert des Feldes ändert, bzw. wenn eine Benutzereingabe stattfindet. Das klingt redundant, Browser sind sich in diesem Punkt allerdings nicht so richtig einig. Nachdem das nun geklärt ist, kannst du schon mal den richtigen Rahmen für den Vergleich schaffen, indem du auf die entsprechenden Ereignisse lauschst. Der eigentliche Vergleich erfolgt später.

const $passwords = $('#Pass,#Pass2')
$passwords.on('change', comparePasswords)
$passwords.on('input', comparePasswords)

Übrig bleibt nun die Funktion comparePasswords.

function comparePasswords () {
  const $password1 = $('#Pass')
  const $password2 = $('#Pass2')
  if ($password1.val() === $password2.val()) {
    // Passwörter sind identisch
    // Evtl. frühere Fehler löschen
    $password1.get(0).setCustomValidity('')
    $password2.get(0).setCustomValidity('')
  } else {
    // Passwörter weichen voneinander ab
    // Fehlermeldungen setzen
    $password1.get(0).setCustomValidity('Passwörter stimmen nicht überein')
    $password2.get(0).setCustomValidity('Passwörter stimmen nicht überein')
  }
}

[JürgenB]

Hallo,

if ($password1.val() === $password2.val()) {

sollte man hier wirklich bei jedem Tastendruck die ganzen Eingaben vergleichen. Bis zum vorletzten Zeichen sind diese ja nicht gleich. Wäre es nicht besser, nur so viele Zeichen zu vergleichen, wie im zweiten Feld eigegeben wurden?

Gruß
Jürgen

[1unitedpower]

if ($password1.val() === $password2.val()) {

sollte man hier wirklich bei jedem Tastendruck die ganzen Eingaben vergleichen. Bis zum vorletzten Zeichen sind diese ja nicht gleich. Wäre es nicht besser, nur so viele Zeichen zu vergleichen, wie im zweiten Feld eigegeben wurden?

Über die Benutzerfreundlichkeit dieser Lösung zu diskutieren ist mir müßig. Sicher hast du recht, sicher könnte man damit teilweise bessere Ergebnisse erzielen. Für ein gutes Ergebnis müsste man aber ohnehin ganz andere Wege einschlagen.

[woodfighter]

Tach,

sollte man hier wirklich bei jedem Tastendruck die ganzen Eingaben vergleichen. Bis zum vorletzten Zeichen sind diese ja nicht gleich. Wäre es nicht besser, nur so viele Zeichen zu vergleichen, wie im zweiten Feld eigegeben wurden?

damit wird ein begonnenes und verlassenes Passwort-Eingabefeld (ah, der Kaffee ist fertig, ich hol mir mal schnell einen) zu einem Sicherheitsproblem, weil man mit dem zweiten Feld das erste Zeichen für Zeichen Brute-forcen kann (ob das ein tatsächliches Problem ist sei dahingestellt).

mfg
Woodfighter

[Christian Kruse]

Hallo woodfighter,

sollte man hier wirklich bei jedem Tastendruck die ganzen Eingaben vergleichen. Bis zum vorletzten Zeichen sind diese ja nicht gleich. Wäre es nicht besser, nur so viele Zeichen zu vergleichen, wie im zweiten Feld eigegeben wurden?

damit wird ein begonnenes und verlassenes Passwort-Eingabefeld (ah, der Kaffee ist fertig, ich hol mir mal schnell einen) zu einem Sicherheitsproblem, weil man mit dem zweiten Feld das erste Zeichen für Zeichen Brute-forcen kann (ob das ein tatsächliches Problem ist sei dahingestellt).

Ähem, solange $("#field").val() via Inspektor-Tools möglich ist halte ich das nicht für ein relevantes Argument…

LG,
CK

[woodfighter]

Tach,

Ähem, solange $("#field").val() via Inspektor-Tools möglich ist halte ich das nicht für ein relevantes Argument…

das stimmt natürlich.

mfg
Woodfighter