Aus Sicherheits- / Implementierungssicht sollte es nicht erforderlich sein, Zeichen außer '\ 0' (was ohnehin schwer zu tippen ist) zu verbieten. Je mehr Zeichen Sie sperren, desto kleiner ist der gesamte Phasenraum möglicher Kennwörter und desto schneller ist es, Kennwörter brutal zu erzwingen. Natürlich werden bei den meisten Kennwortschätzungen Wörterbuchwörter anstelle systematischer Suchen in der Eingabedomäne verwendet ...

Aus Sicht der Benutzerfreundlichkeit werden einige Zeichen jedoch nicht gleich eingegeben Weg auf verschiedenen Maschinen. Als Beispiel habe ich hier zwei verschiedene Computer, auf denen Shift-3 auf dem einen # und auf dem anderen £ erzeugt. Wenn ich ein Passwort eingebe, werden beide als '*' angezeigt, sodass ich nicht weiß, ob ich es richtig verstanden habe oder nicht. Einige Leute denken, das könnte die Leute genug verwirren, um diese Charaktere nicht mehr zuzulassen. Ich denke nicht, dass es sich lohnt. Die meisten echten Menschen greifen von einem oder vielleicht zwei Computern auf echte Dienste zu und geben in ihren Passwörtern nicht viele erweiterte Zeichen ein.

Es können Probleme mit Nicht-ASCII-Zeichen auftreten. Ein Passwort ist eine Folge von Glyphen, aber die Passwortverarbeitung (Hashing) erfordert eine Folge von Bits , sodass es eine deterministische Möglichkeit geben muss, Glyphen in Bits umzuwandeln. Dies ist der ganze trübe Sumpf von Codepages. Selbst wenn Sie sich an Unicode halten, treten Probleme auf:

• Ein einzelnes Zeichen kann mehrere Zerlegungen als Codepunkte haben. Zum Beispiel kann das "é" -Zeichen (das auf Französisch sehr häufig vorkommt) entweder als einzelner Codepunkt U + 00E9 oder als Sequenz U + 0065 U + 0301 codiert werden; Beide Sequenzen sollen äquivalent sein. Ob Sie das eine oder das andere erhalten, hängt von den vom Eingabegerät verwendeten Konventionen ab.

• Eine Unicode-Zeichenfolge ist eine Folge von Codepunkten (welche sind) Ganzzahlen im Bereich von 0 bis 1114110). Es gibt verschiedene Standardcodierungen zum Konvertieren einer solchen Sequenz in Bytes. Am häufigsten sind UTF-8, UTF-16 (Big-Endian), UTF-16 (Little-Endian), UTF-32 (Big-Endian) und UTF-32 (Little-Endian). Jedes dieser Elemente kann mit einer Stückliste beginnen oder nicht.

Daher kann ein einzelnes "é" mit mindestens zwanzig sinnvoll in Bytes codiert werden verschiedene Varianten, und das ist, wenn man sich an "Mainstream Unicode" hält. Latin-1-Codierung oder das Microsoft-Gegenstück ist ebenfalls weit verbreitet. Stellen Sie daher sicher, dass 21. Welche Codierung für eine bestimmte Software verwendet wird, kann von vielen Faktoren abhängen. einschließlich des Gebietsschemas . Es ist störend, wenn sich der Benutzer nicht mehr an seinem Computer anmelden kann, weil er die Konfiguration von "Kanadisch - Englisch" auf "Kanadisch - Französisch" umgestellt hat.

Experimentell werden die meisten Probleme dieser Art vermieden, indem Kennwörter auf den Bereich von druckbaren ASCII-Zeichen beschränkt werden (solche mit Codes zwischen 32 und 126 - persönlich würde ich das tun Vermeiden Sie Leerzeichen, machen Sie also 33 bis 126) und erzwingen Sie die Monobyte-Codierung (keine Stückliste, ein Zeichen wird zu einem Byte). Da Passwörter ohne visuelles Feedback auf verschiedenen Tastaturen eingegeben werden sollen, sollte die Liste der Zeichen für eine optimale Benutzerfreundlichkeit noch eingeschränkter sein (ich kämpfe täglich mit kanadischen Layouts, bei denen das, was auf der Tastatur geschrieben ist, nicht funktioniert müssen unbedingt mit dem übereinstimmen, was der Computer für richtig hält, insbesondere wenn eine oder zwei verschachtelte RDP-Verbindungen durchlaufen werden (die Zeichen '<', '>' und '\' bewegen sich am häufigsten). Mit nur Buchstaben (Groß- und Kleinbuchstaben) und Ziffern ist alles in Ordnung.

Sie können sagen, dass der Benutzer verantwortlich ist. Es steht ihm frei, beliebige Zeichen zu verwenden, solange er sich mit dem Problem der Eingabe befasst. Aber das ist letztendlich nicht haltbar: Wenn Benutzer Probleme haben, rufen sie Ihren Helpdesk an, und Sie müssen einen Teil ihrer Fehler annehmen.

Wenn Sie zufällige Passwörter generieren, ist es eine gute Idee, Zeichen zu vermeiden, die für andere verwechselt werden können. Zum Beispiel (Symbole ignorieren):

• Kleinbuchstaben: l, o
• Großbuchstaben: I, O
• Zahlen: 1, 0

Zusätzlich zum Zulassen aller Zeichen sollten Sie eine sehr großzügige maximale Länge im Kennwortfeld festlegen, um Personen zu unterstützen, die den Passphrasenansatz für Kennwörter verwenden.

Der Ausdruck "Mein Kennwort ist nur in Kleinbuchstaben" lautet eigentlich eine vernünftig starke Passphrase aufgrund ihrer Länge.

Sie sollten keine Zeichen verbieten. Möglicherweise möchten Sie verhindern, dass Kennwörter kürzer als 6 Zeichen sind. Und dann sollten Sie bcrypt verwenden, um das Passwort zu hashen.

Ich denke, dass wir nur alphanumerische Zeichen haben, wenn keine 'virtuelle Tastatur' oder ein ähnliches Werkzeug verfügbar ist, das Zeichen auf einheitliche Weise erzeugt. Die Position aller anderen Teile kann auf verschiedenen Tastaturen unterschiedlich sein. Wenn ein Benutzer von einem anderen Standort aus auf den Dienst zugreifen sollte, kann dies dazu führen, dass er effizient außer Betrieb gesetzt wird.

Ich würde vorschlagen, die virtuelle Tastatur zu verwenden, um genau die gleichen Zeichendarstellungen (wie oben bereits über Unicode gesagt) auf dieselbe Weise zu senden, unabhängig davon, welches System / welche Tastatur / was auch immer verwendet wird. Daher müssen keine Zeichen ausgeschlossen werden, die für ein Schlüsselwort eingegeben werden könnten.

Es gibt einige Zeichen, die Probleme verursachen können:

* ,? und%: Da diese häufig als Platzhalter verwendet werden, können sie die zugrunde liegende Programmiersprache verwirren.

Tab, Return, NewLine, Vertical Tab, Escape: Solche Sonderzeichen können seltsames Verhalten in Ihrer Programmiersprache ODER im vom Kunden verwendeten Browser hervorrufen. (Wenn der Kunde mehrere verschiedene Browser verwendet, ist es durchaus möglich, dass einer die Eingabe dieser Browser zulässt und ein anderer Browser dies nicht. Der Kunde wird in diesem Browser effektiv von seinem Konto ausgeschlossen.)

\ wird häufig als behandelt ein Escape-Zeichen, das dem Zeichen eine besondere Bedeutung gibt.
ZB "\ n" ist in vielen Fällen eine neue Zeile. "\ t" ist ein Tabulator.
Wenn Ihre Programmiersprache (oder der Browser des Kunden) dies tut, haben Sie wieder die Möglichkeit, die oben genannten Zeichen zu empfangen.
Daher ist es wahrscheinlich am besten, \ ganz zu deaktivieren nur um sicher zu gehen.

Wenn Sie alphanumerische Groß- und Kleinbuchstaben zulassen und die minimale Kennwortlänge auf acht Zeichen festlegen, sollten Sie in Ordnung sein. Das Zulassen anderer Zeichen wirft Probleme mit anderen Tastaturen auf.