Frage:
Welche Zeichen sollte ich in Passwörtern nicht zulassen?
Jonas
2011-02-10 23:08:48 UTC
view on stackexchange narkive permalink

Ich plane die Entwicklung einer Website, für die die Benutzer einen Benutzernamen und ein Passwort registrieren müssen. Wenn ich den Benutzer ein Passwort auswählen lasse, welche Zeichen sollte ich den Benutzern erlauben, das Passwort zu verwenden? Gibt es welche, die ich aufgrund von Sicherheitsproblemen mit dem http-Protokoll oder der Implementierungssprache nicht sollte?

Ich habe mich noch nicht für eine Implementierungssprache entschieden, werde aber Linux verwenden.

Ich hoffe, Sie werden HTTPS verwenden. Nicht HTTP.
Acht antworten:
#1
+43
user185
2011-02-10 23:21:14 UTC
view on stackexchange narkive permalink

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.

@GrahamLee - war mitten in der Antwort und Sie haben alles abgedeckt, was ich sagen wollte. Habe eine +1 :-)
http://xkcd.com/327/
@symcbean: "es sollte nicht geben", nicht "es gibt keine Chance, dass du etwas falsch machst" ;-)
Vielleicht ist es nützlich, eine Warnung wie * Sie haben Zeichen in Ihrem Passwort, die sich nicht auf jeder Tastatur an derselben Stelle befinden. Sind Sie sicher, dass Sie fortfahren möchten? * Bei genauer Betrachtung bleiben jedoch nur etwa 20 Tasten übrig, die auf den meisten Tastaturen gleich sind (ohne Dvorak und dergleichen).
Stellen Sie außerdem sicher, dass Sie beim Speichern in einer SQL-Datenbank "" entkommen!
@Earlz Bei dieser Frage geht es um ** Passwort **. Wenn Sie es im Klartext speichern, machen Sie es falsch.
@Holy oh wow. Ja, ignoriere das, ich war für eine Sekunde dumm, lol
Warum würden Sie "\ 0" überhaupt nicht zulassen?
Weil es wahrscheinlicher ist, dass es von der zugrunde liegenden Implementierung falsch behandelt wird. Sie möchten Kennwörter nicht abschneiden, nur weil sie irgendwo im Darm Ihrer Laufzeit in C-Zeichenfolgen konvertiert werden.
Wenn der Benutzer einen Passwort-Manager verwendet (wie er es definitiv sollte), sollte das Problem der Eingabe des Passworts strittig sein ...
#2
+17
Thomas Pornin
2013-02-03 03:28:19 UTC
view on stackexchange narkive permalink

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.

Guter Beitrag, aber ich würde den Platz definitiv nicht meiden. Die Verwendung von Sätzen als Passwort ist eigentlich keine schlechte Praxis (siehe auch http://www.codinghorror.com/blog/2005/07/passwords-vs-pass-phrases). HTML, obwohl offensichtlich keine berühmten Zitate wie im Beispiel verwenden :))
Warum Leerzeichen vermeiden? Ersetzen Sie sie möglicherweise, wenn Sie der Meinung sind, dass dies irgendwo zu Kompatibilitätsproblemen führen kann, aber es stört mich wirklich, wenn ich keine anständigen Passphrasen erstellen kann. Niemand hat Leerzeichen in Passwörtern, weshalb ich sie sehr häufig benutze.
Auf einer typischen Tastatur erzeugt die Leertaste einen unverwechselbaren Klang und ist somit eine leichte Beute für Schulter-Surfer.
Man sollte wahrscheinlich sagen "Wenn Sie Unicode verwenden, dann wie immer, gibt es Probleme im Gange" anstelle von "selbst wenn Sie Unicode verwenden". Es ist Unicode, das (wie immer!) Probleme verursacht, keine Codepages. Die Eingabe des gleichen Passworts mit der gleichen Codepage führt zuverlässig zu genau den gleichen Bits. Es ist nur Unicode, das alles vermasselt. Wenn Sie dasselbe PW mit einer anderen Codepage eingeben, werden unterschiedliche Bits erzeugt. Dies ist eigentlich ein winziges Stück Extra-Sicherheit (2-3 Bit, um die Codepage zu erraten) für einen Wörterbuchangriff. Dies erschwert auch die Verwendung eines Snooped-PW (möglicherweise wird beim Versuch, CPs zu verwenden, das Anmeldefehlerlimit erreicht).
#3
+11
Justin Morgan
2011-02-13 02:03:01 UTC
view on stackexchange narkive permalink

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
+1 Stellen Sie sich nun vor, Sie führen eine CA-Schlüsselunterzeichnungszeremonie durch und Ihr Etikettendrucker lässt 1 und l ununterscheidbar aussehen.
Verwenden sie nicht einfach Haftnotizen auf den Monitoren für die Passwörter auf den Hauptschlüsseln?
#4
+6
Antony
2011-02-21 07:12:20 UTC
view on stackexchange narkive permalink

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.

#5
+2
Stephen Touset
2013-02-03 10:25:52 UTC
view on stackexchange narkive permalink

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 würde vehement gegen ein System protestieren, das die Rückgabe von Passwörtern erlaubt.
Viel Glück beim Abrufen eines ASCII-LF aus einem Webformular.
#6
  0
Konstantin Boyandin
2013-02-03 07:42:05 UTC
view on stackexchange narkive permalink

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.

#7
  0
Tonny
2014-02-08 05:30:30 UTC
view on stackexchange narkive permalink

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.

Es tut mir leid für die Ablehnung, aber es gibt einen Grund dafür: Probleme in der zugrunde liegenden Programmiersprache sind * nie * ein Grund, die Verwendung von Zeichen zu verbieten. Dafür sind mysql_real_escape_string oder besser parametrisierte Abfragen gedacht. Benutzerdaten sollten niemals als ausführbarer Code interpretiert werden, unabhängig davon, ob dies der Fall ist oder nicht. Sternchen, Fragezeichen, Prozentzeichen und Backslashes sind perfekte Zeichen, die ich verwende und die ich weiterhin in meinen Passwörtern verwenden möchte. Haben wir sie nicht vor der Lagerung gehasht?
@Luc Die Verwendung von "\ 0" in einer Zeichenfolge birgt das Risiko einer stillen Kürzung in C und seinen Derivaten. Daher erscheint es vernünftig, dies zu verbieten.`\ r`,` \ n` und `\ t` leiden unter Eingabeproblemen.Für ein gutes Maß würde ich das auf alle Steuerzeichen erweitern (ASCII-Code <32)
@CodesInChaos Steuerzeichen ja, diese haben keine visuelle Darstellung und kommen daher in normalen Passwörtern nicht vor.Das Literal `\ 0` (also ASCII 92 und ASCII 48, nicht ASCII 0) sollte ebenfalls vollkommen in Ordnung sein, da es nicht interpretiert, sondern wörtlich verwendet werden sollte, aber ich denke, Sie meinen ASCII 0, in diesem Fall ist es ein Steuerzeichen undIch würde zustimmen.
#8
-7
OhBrian
2011-02-14 06:33:18 UTC
view on stackexchange narkive permalink

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.

Wenn jemand dies implementieren würde, würde ich seine Website nicht verwenden, da keines meiner Passwörter funktionieren würde.
Dies ist sehr unsicher und leicht zu knacken. Wenn Sie sich auf obere und untere Zeichen beschränken, sollte Ihre Mindestlänge 17 betragen.
@this.josh Mindestlänge von 17? Okay, hier ist eine MD5-Summe eines 8-stelligen Nur-Buchstaben-Passworts: `124c6ffa6d57c5909e7a403293aed173`. Erstellt mit `echo -n secret | md5sum`. Da dies weniger als die Quadratwurzel der Stärke ist, von der Sie sagten, dass sie das "Minimum" vor mehr als 2 Jahren ist, gehe ich davon aus, dass es kein Problem sein muss, eine Commodity-GPU zu knacken (mit Hashcat oder Barswf oder so). Viel Glück. (Ehrlich gesagt denke ich, dass es machbar ist, aber md5 sollte sowieso nicht für die Passwortspeicherung verwendet werden. Trotzdem frage ich mich, ob jemand es herausfinden kann.)
@Luc für Passwort in {{A..Z}, {a..z}} {{A..Z}, {a..z}} {{A..Z}, {a..z}} { {A..Z}, {a..z}} {{A..Z}, {a..z}} {{A..Z}, {a..z}} {{A..Z }, {a..z}} {{A..Z}, {a..z}}; Echo -n $ Passwort | md5sum >> Regenbogen; echo $ password >> rainbow; erledigt; echo "8-stellige Nur-Buchstaben-Regenbogentabellen für md5, einfach grep für md5 und Passwort abrufen, keine GPU erforderlich"
@this.josh dann mach es.
@Luc `pzNraRqZ` (ich weiß, es ist fast 3 Jahre später)
@Kade Schön.Darf ich fragen, wie viel Aufwand das gekostet hat?Wie lauten die Systemanforderungen und wie lange hat es gedauert?


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 2.0-Lizenz, unter der er vertrieben wird.
Loading...