it-swarm.com.de

Sollten Benutzer beim Erstellen eines Kennworts ein beliebiges Sonderzeichen verwenden dürfen?

Ich bin auf eine Reihe von Login-Konfigurationseinstellungen gestoßen, bei denen es ein Liste der zulässigen Sonderzeichen gibt, und habe mich gefragt:

Entspricht diese Einschränkung einem bestimmten Sicherheits- oder Usability-Bedarf?

Beispiel: Eine Liste von Sonderzeichen, die von Oracle Identity Manager und Microsoft Active Directory für das Kennwortfeld unterstützt werden:

enter image description here

pdate :

Danke an alle für die großzügige Antwort!

Jedes Mal, wenn ich eine Frage gestellt habe, die Sicherheit und Benutzerfreundlichkeit betrifft, scheint es eine klare Trennung zwischen Befürwortern auf jeder Seite zu geben. Dies muss jedoch nicht so sein, da dies ein Bereich ist, der viele Kompromisse und Kompromisse erfordert… UX hängt davon ab!

75
Okavango

Wenn der Benutzer es eingeben kann, sollte es in seinem Passwort erlaubt sein.

Jemandem zu sagen, was er in seinem Passwort verwenden kann und was nicht, fühlt sich für den Benutzer immer falsch an. Passwörter sind derzeit die universellste Methode zur Authentifizierung. Das Verhindern, dass Benutzer etwas eingeben , bedeutet im Wesentlichen, ihnen zu sagen, wer sie sein können oder nicht.

1. Jedes druckbare Zeichen, das ein Benutzer eingibt, sollte zulässig sein.

Die folgenden Zeichen sind in Ordnung ...

'A', 'a', 'á', 'Æ', 'æ', 'Ñ', 'ñ', '-', '_', ' ' (space), '\t' (tab), '\n' (newline), ...

Nur weil ich nicht weiß, wie ich eine einreichen soll TAB oder ENTER Zeichen als Teil meines Passworts geben mir nicht das Recht, andere daran zu hindern.
(Keine Sorge, nur wenige Leute werden versuchen, eine einzureichen ENTER Charakter als Teil ihres Passworts, aber das Zulassen der wenigen, die dies tun, wird ihren Respekt verdienen.)

2. Schlüssel, die kein druckbares Zeichen anzeigen, sollten nicht zugelassen werden.

Die Gründe hierfür sollten offensichtlich sein, aber der Vollständigkeit halber werde ich die folgenden Schlüssel erwähnen, die erkannt werden können, aber für andere Aktionen reserviert sind. Beispielsweise sollte eine Passworteingabe nicht aufzeichnen, dass die Schicht mehrmals getroffen wurde ...

[ctrl], [alt], [shift], [arrow keys], [Apple key], [windows key], etc.

3. Wenn bestimmte Zeichen nicht zugelassen werden, stellen Benutzer Ihre Sicherheit in Frage.

Wenn Sie verhindern, dass Benutzer bestimmte Zeichen in ihr Kennwort eingeben, ärgert dies nicht nur die Benutzer, sondern viele von ihnen fragen sich, was Sie sonst noch tun, was nicht sicher ist.

Sie können genauso gut sagen ...

"Hey, wir möchten unsere Anwendung nicht reparieren, um mit Sonderzeichen richtig umzugehen. Würde es Ihnen etwas ausmachen, uns zu helfen, indem Sie Ihr Passwort weniger sicher machen?"

Die folgenden Regeln ermöglichen eine sichere Eingabe und verhindern gleichzeitig, dass ein Benutzer jemals hängen bleibt:

  • Zeigen Sie nicht die Zeichen an, die der Benutzer in Kennwortfelder eingibt (auf Mobilgeräten gibt es einige Ausnahmen).

  • Wenn der Benutzer sein Passwort zweimal eingibt, reicht dies normalerweise aus, um ihn wissen zu lassen, dass er es richtig gemacht hat (d. H. Nicht versehentlich unbeabsichtigte Leerzeichen usw. hinzugefügt hat).

  • Ein Mechanismus zum Zurücksetzen des Passworts ist wichtig, um alle Fälle einer versehentlichen Sperrung zu behandeln.

4. Das Ermutigen eines Benutzers, weitere hinzuzufügen, ist nicht dasselbe wie das Verbot von Zeichen.

Eine Möglichkeit, einem Benutzer zu helfen, ein sicheres Passwort zu finden, besteht darin, daraus ein Spiel zu machen ...

password strength indicator

5. Die Zukunft der Authentifizierung

" Die Technologie, die tote Passwörter tötet " ist ein ziemlich guter Gizmodo-Artikel, in dem die Probleme besprochen werden, mit denen wir alle bei Passwörtern konfrontiert sind. Es geht auch um einige neue Muster, die möglicherweise eines Tages Passwörter ersetzen könnten.

In vielen mobilen Anwendungen können Benutzer Passwörter im Klartext ein- oder ausblenden, um die Benutzerfreundlichkeit zu erhöhen und eine Eintrittsbarriere zu beseitigen. Ich würde dies immer noch vermeiden, da das Problem, das es verursacht, schlimmer ist als das Problem, das es löst.

Selbst mit einem sehr intuitiven Mechanismus zum Ein-/Ausblenden eines Passworts sagen 60% der Benutzer immer noch, dass es falsch ist, Passwörter im Klartext zu sehen .

Laut demselben Artikel scheint Touch ID auf dem richtigen Weg zu sein und gewinnt leicht, was die Benutzerfreundlichkeit betrifft. Touch ID weist immer noch einige Hauptprobleme auf, die es unpraktisch machen. Das größte Problem ist, dass es nur auf ausgewählten Geräten funktioniert und Probleme mit einer Person hat, die mehrere Konten kontrolliert.

Die Gesichtserkennung ist ein weiterer Konkurrent, da immer mehr Kameras mit hoher Pixeldichte ihren Weg in die Welt finden. Bei diesem Ansatz sorgen sich die Menschen jedoch häufig um die Privatsphäre.

Das einzige Problem, das all diese neuen Authentifizierungsversuche gemeinsam haben, ist Folgendes: Sie sind das Kennwort.

Es ist tatsächlich viel einfacher zu fälschen wer du bist als was du weißt. Sobald Sie kompromittiert wurden, ist es nahezu unmöglich, Änderungen vorzunehmen (z. B. Ihre Fingerabdrücke).

Passwörter sind lange Zeit der Authentifizierungsmechanismus der Wahl, also ...

Bitte beschränken Sie mein Passwort nicht auf beliebige Zeichen. Vielen Dank!

119
DaveAlger

Wenn eine Site erfordert, dass Kennwörter nur bestimmte Zeichencodes enthalten, kann ein Benutzer das Kennwort in fast jedes Gerät eingeben, das diese Zeichen erzeugen kann. Wenn das Kennwort Zeichencodes enthält, die auf einigen Geräten eingegeben werden können, auf anderen jedoch nicht, muss sich ein Benutzer, der ein Kennwort auf einem Gerät erstellt, das die darin enthaltenen Codes eingeben kann, sich aber später mit einem Gerät anmelden kann, das dies nicht kann. würde effektiv von seinem Konto gesperrt werden.

Auf fast jeder vernünftigen Plattform sind die 94 druckbaren Zeichen ASCII) deutlich voneinander zu unterscheiden. Auch wenn eine Schriftart ärgerlicherweise identische Glyphen für I und l oder für verwendet 0 und O haben Personen, die solche Zeichen eingeben, im Allgemeinen keinen Zweifel daran, welche sie eingegeben haben. Im Gegensatz dazu könnte ein Benutzer auf einigen Plattformen denken, dass er einen Charakter wie ɸ wenn er tatsächlich ein φ; Wenn ein solcher Benutzer zu einem Computer wechselt, auf dem Zeichen anders eingegeben werden, kann er möglicherweise nicht auf sein Konto zugreifen, es sei denn oder bis er herausgefunden hat, welche Zeichen er möglicherweise zur Eingabe seines Kennworts verwendet hat.

Die Dinge werden noch komplizierter, wenn man Dinge wie das Kombinieren diakritischer Zeichen berücksichtigt. Einige Zeichen wie ë haben zwei legitime Darstellungen - entweder einen einzelnen "lateinischen Kleinbuchstaben E mit Diaeresis" [Code 0x000EB] oder eine "kombinierte Diaeresis" [Code 0x00308], gefolgt von "lateinischem Kleinbuchstaben E" [0x00065]. Bei einigen Geräten kann der Benutzer möglicherweise nicht steuern, welches Formular eingegeben wird. Idealerweise wird das Kennwort vor dem Hashing in eine bekannte normalisierte Form konvertiert, aber es ist keineswegs sicher, dass der gesamte Code, der versucht, Unicode-Zeichenfolgen zu "normalisieren", immer auf die gleiche Weise funktioniert (auch wenn dies angegeben ist, bedeutet dies nicht, dass dies der Fall ist tatsächlich wird).

35
supercat

Ich möchte DaveAlger etwas hinzufügen. Ich erstelle wie viele Menschen Algorithmen, um mich besser an Passwörter zu erinnern. Ich habe mit vielen Menschen (auf informelle Weise) über Passwörter gesprochen und viele Einwände gehört

  • warum kann ich keinen Teil meiner E-Mail oder meines Benutzernamens in meinem Passwort verwenden?
  • warum gibt es eine Zeichenbeschränkung? (beeinflusst meinen Algorithmus)
  • warum kann ich keine Sonderzeichen verwenden?
  • warum muss ich Großbuchstaben, Zahlen oder Sonderzeichen verwenden?

Fast jeder ist frustriert, wenn er gezwungen ist, sein Passwort zu ändern. Wenn das übermittelte Kennwort als unsicher eingestuft wird (Beispiel 1234, 1111 oder qwerty), teilen Sie dem Benutzer mit, dass das Kennwort als unsicher abgelehnt wird. Stellen Sie jedoch sicher, dass das Passwort tatsächlich unsicher ist, auch wenn es keine individuellen Anforderungen erfüllt.

Das Passwort blueOrangeMetsWasSheaNowCiti ist sicherer als # $ 78rt, obwohl keine Zahlen oder Sonderzeichen verwendet werden.

Das Einschränken hilft nicht bei der Benutzerfreundlichkeit, da es nur Benutzer frustrieren kann, und obwohl ich kein Sicherheitsexperte bin, kann ich nicht erkennen, wie das Einschränken eines Zeichensatzes in irgendeiner Weise zur Sicherung eines Systems beitragen kann.

20
Mayo

Dies kann aus Sicht der Benutzerfreundlichkeit und des Supports sinnvoll sein.

Wenn das Zeichen nicht ohne Verwendung von Alt-Codes oder Einfügen auf einer Tastatur/einem Telefon eingegeben werden kann.

Beachten Sie, dass die aktivsten internetfähigen Geräte über Touchscreens verfügen. Ihr Benutzer könnte das Konto von seinem Laptop aus erstellen und dann versuchen, mit seinem Telefon auf das Konto zuzugreifen, das nicht in der Lage ist, das Zeichen Æ einzugeben.

Alle Leerzeichen sollten als generisches Leerzeichen bereinigt, von vorne und hinten abgeschnitten und mehrere Leerzeichen hintereinander ignoriert und als ein einziges Leerzeichen behandelt werden. Warum? Weil viele Dinge Probleme mit Leerzeichen haben, insbesondere führende, nachfolgende und mehrere Leerzeichen hintereinander.

Während Sie wahrscheinlich Leerzeichen zulassen sollten (die Leute verwenden jetzt gerne Phrasen), möchten Sie Ihren Benutzer möglicherweise darüber informieren, wie Sie sein Passwort aufgeräumt haben, aber dass er sich darüber keine Sorgen machen muss, wenn er es so gewohnt ist, es einzugeben .

Das Zulassen von Unicode-Zeichen, die dann über HTTP weitergeleitet werden müssen, ist eine weitere potenzielle Support-Prüfung.

3
Andrew Hoffman

Es hängt davon ab, ob.

Wenn Sie eine relativ starke Kontrolle über den Kennworteingabemechanismus (Tastaturlayouts, Software-Stacks usw.) haben, ist es eine gute Idee, Benutzer frei eingeben zu lassen, was sie möchten, da dadurch der verfügbare Kennwortspeicher maximiert wird. Jemand, der eine englischsprachige Website angreift, wird wahrscheinlich nicht einmal offensichtliche Dinge wie "كلمة المرور" ausprobieren (was Google Translate mir versichert, dass Arabisch für "Passwort" ist). In einem solchen Fall spielt das Codieren von Verwechslungen keine Rolle, da jede Verwechslung auf allen Systemen gleich ist und sich selbst aufhebt.

Wenn Sie jedoch versuchen, eine möglichst breite Palette von Systemen zu unterstützen, sollten Sie die Kennwörter auf die 95 druckbaren Zeichen ASCII) beschränken, um die Programmierung fortzusetzen und Albträume zu unterstützen ein Minimum. Alles zu unterstützen bedeutet, sich mit Homoglyphen (Α, А und A zu befassen, die mit einem Menschen identisch sind, aber unterschiedliche Bytewerte haben), doppelte Zeichen (das "Mikrozeichen") "µ und das" griechische Kleinbuchstaben mu "μ stellen dasselbe Zeichen dar, sind jedoch mit unterschiedlichen Bytewerten codiert), unterschiedlich Zusammensetzungsformen (ñ und ñ sehen gleich aus, aber das erste ist ein" n " gefolgt von einer kombinierenden Tilde, während die zweite ein einzelnes vorkomponiertes Zeichen ist) und unterschiedlich Reihenfolge der kombinierten Zeichen (ế kann entweder als "e + akuter Akzent + Zirkumflex-Akzent" oder "e + Zirkumflex" ausgedrückt werden Akzent + akuter Akzent ", den ein Computer als anders ansieht) - und das nur innerhalb von Unicode. Verstümmelte Codierungstransformationen kann bedeuten, dass jemand versucht Die Eingabe von "Pässword" auf einem ISO 8859-1-System wird von einem ISO 8859-7-System als "Pδssword" interpretiert.

3
Mark

Ein Problem, das ich bei Nicht-ASCII-Passwörtern gesehen habe, ist, dass einige Systeme Zeichen und andere codierungsspezifische Codepunkte behandeln. Das Zeichen "א" kann je nach Codierung auf unterschiedliche Weise dargestellt werden, und manchmal kann dasselbe Zeichen auf verschiedene Arten dargestellt werden ("é" kann gleichermaßen U00E9 Oder U0065 U0301 Sein).

Betrachten Sie den Übergang Python2 -> Python3. Das Serialisieren von "שלום" in Python 2 und das anschließende Vergleichen mit demselben Wert, der mit Python 3 serialisiert wurde, führt aufgrund der Änderungen in der Art zu FALSE als Python 3 Zeichenfolgen werden intern in Python dargestellt.

PHP hat ein ähnliches Missgeschick: Es handelt sich um Bytes, nicht um Zeichen. Ein Benutzer, der auf einer Seite mit CP-1252-Codierung "שלום" eingegeben hat, kann sich möglicherweise nicht auf einer Seite mit UTF-8-Codierung anmelden. Kombinieren Sie dies mit dem Host von Codierungsproblemen, die mit der Verwendung der mysql_* - Treiber verbunden waren (weniger bei den PDO-Treibern, die dies vereinfachen), und das Problem verschärft sich.

In PHP habe ich mich mit dem Problem auf nicht englischen Websites befasst, indem ich sichergestellt habe, dass ich über UTF-8 eine ordnungsgemäße Verbindung zur Datenbank herstelle (viel einfacher seit PHP 5.3.3, aber vorher problematisch, selbst mit PDO, so sehr, dass ich mich noch an die kritische Versionsnummer erinnere), vorbereitete Abfragen und korrektes Hashing verwende und die Seite immer als UTF-8 diene. Ich habe jedoch kein Ende der Probleme gesehen, mit denen meine weniger pedantischen Kollegen mit dem Problem konfrontiert sind.

3
dotancohen

Ja, leider sind die Einschränkungen für Zeichen, die der Benutzer im Kennwort verwenden kann, aus UX-Sicht sinnvoll.

Wenn Sie einen weltweiten Dienst betreiben, möchten Sie, dass sich Ihre Benutzer von allen Orten der Welt aus anmelden können. Wenn dies der Fall ist, müssen Sie berücksichtigen, dass die Tastaturen leider nicht standardisiert sind.

Wenn das Layout der Grundzeichen variabel ist. Zum Beispiel wissen Götter in Deutschland warum, sie haben 'Z' gegen 'Y' ausgetauscht und sie haben einen kompletten Mischmasch mit anderen Charakteren gemacht.

Wenn es Ihnen als Benutzer gelingt, find auf der Tastatur anzugeben, ist es dennoch sehr wahrscheinlich, dass Sie keine "nationalen" Zeichen Ihrer Wahl eingeben können, da jedes Land über eine eigene Tastatur verfügt Layout (virtuell oder in extremen Fällen, wie in Deutschland, sogar physisch) und die Möglichkeit für jeden Benutzer, beliebig Tastaturlayout zu wählen, ist keine Option, zumindest nicht auf Windows-Computern.

Bitte beachten Sie, dass die meisten Benutzer sind sich dessen nicht bewusst dieser Probleme.

Es gibt also praktische Gründe, die Auswahl der Zeichen im Kennwort auf den Satz zu beschränken, der (wahrscheinlich) von jedem Benutzer von jedem Computer aus eingegeben werden kann.

2
Danubian Sailor

Authentifizierung und Sicherheit sind entscheidend. Eine Sicherheitsverletzung wird Sie töten.

Haben Sie eine Idee, was zwischen Tastatur und Server passiert? Sie haben Normalisierung, Codierung, Mehrdeutigkeiten in Unicode, Serialisierung, NAT, Man-in-the-Middle und andere Maßnahmen. Dies ist eine sichere End-to-End-Transaktion, die für die gesamte Sitzung verwendet wird. Böse Jungs wollen all das ausnutzen.

Eine übliche Sicherheitspraxis besteht darin, die Angriffsfläche zu begrenzen und wie ein Soldat zu schützen.

Dies bedeutet nicht, dass Programmierer faul sind: Es geht darum, eine sehr sensible und kritische Funktion zu schützen, die viele Bösewichte ausnutzen wollen.

Zu sagen "Ich möchte einen beliebigen Charakter verwenden, mich aber beschützen" ist wie zu sagen "Akzeptiere jede Form von Ausweis, aber versichere mir, dass sie so sind, wie sie sagen, dass sie sind". Ich kann mit meinem Schulausweis aus einem Grund nicht in ein Flugzeug steigen: Es ist nicht so sicher.

Unter dem Strich kann ein funktionales sicheres Passwort aus 128 Zeichen erstellt werden. Es gibt keinen Sicherheitsgrund, mehr zu unterstützen. Alle Unicode zu unterstützen ist eine unnötige Sicherheitslücke.

1
paparazzo

Einige Richtlinien:

  • Lassen Sie den Benutzer ein beliebiges Zeichen im Bereich ASCII von 32 (Leerzeichen) bis 126 (~) eingeben - diese sollten in jedem Zeichencode identisch sein.

  • Wenn Sie Ihre Benutzer auf weniger Zeichen beschränken, werden sie nur frustriert und gezwungen, weniger sichere oder schwerere Kennwörter zu wählen.

  • Die folgenden Zeichen ASCII 32 (und ASCII 127 = Löschen)) haben eine besondere Bedeutung, z. B. ESC, Eingabe (Formular senden), Tabulator (Sprungfeld) und andere Zeichen, die sind nicht zur Eingabe gedacht und sollten daher nicht akzeptiert werden.

  • Zeichen über ASCII 127 können auf einigen Tastaturen oder Geräten möglicherweise nicht eingegeben werden (verhindert möglicherweise die Anmeldung per Telefon oder über andere PCs im Ausland) und erfordern Unicode-Speicher (weniger problematisch, müssen Sie jedoch sei dir dessen bewusst)

  • Begrenzen Sie die Länge nicht zu stark - z. Lassen Sie Benutzer 10 Zeichen eingeben, z. bis zu 50 oder bis 100.

Weitere Details zu Passwörtern in meiner Antwort hier .

1
Danny Varod

Was ist, wenn es zwei Wochen dauert, bis das Passwort durch einen Brief an meine Privatadresse zurückgesetzt wird und ich im Urlaub nicht auf meine Bank zugreifen kann, da sie ein Zeichen in meinem Passwort sind, das ich auf meinem iPhone nicht eingeben kann.

Werde ich der Bank die Schuld geben, werde ich erwägen, die Bank zu wechseln ...

Was ist, wenn mein Rücken zu einem späteren Zeitpunkt entscheidet, dass er Dropdown-Listen verwenden möchte, um ein Passwort anstelle eines Textfelds einzugeben?.

Was ist, wenn die Tastatur, die ich heute verwende, ein anderes Zeichen ausgibt, wenn ich £ drücke?

Erstellen wir angesichts des Risikos beim Zurücksetzen von Passwörtern nur ein anderes Risiko, indem wir Benutzern erlauben, ein Passwort zu haben, das mit größerer Wahrscheinlichkeit zurückgesetzt werden muss?

Wenn das Passwort jedoch nur von der Website zurückgesetzt werden kann, die mir eine E-Mail sendet, sollte alles im Passwort zulässig sein.

0
Ian

Es ist eine gute Idee, zulässige Zeichen in Kennwörtern auf eine vernünftige Teilmenge druckbarer Zeichen zu beschränken. Mehr Flexibilität ist nicht immer besser. Deshalb haben wir Geschwindigkeitsbegrenzungen auf Straßen. Bei der Benutzerfreundlichkeit geht es häufig darum, Benutzer vor ihrer natürlichen Fähigkeit zu schützen, sich selbst in den Fuß zu schießen.

Unter dem Gesichtspunkt der serverseitigen Sicherheit gibt es kein Problem bei der Unterstützung vollständiger Unicode-Kennwörter. Selbst wenn Sie nicht mit verrückten Zeichen auf der Serverseite umgehen möchten, kann ein wenig Javascript-Codierung alle Kennwörter leicht in Hexadezimalschreibweise vorkonvertieren, bevor sie vom Server gesendet und verarbeitet werden. Aus den oben genannten Gründen sollte man dies jedoch tun und sich auch auf eine vernünftige Teilmenge druckbarer Zeichen beschränken.

0
Atsby