Frage:
Warum Sonderzeichen in einem Passwort nicht zulassen?
Gary
2012-07-14 01:09:30 UTC
view on stackexchange narkive permalink

Der Schuldige in diesem Fall ist eine bestimmte (und besonders große) Bank, die keine Sonderzeichen (jeglicher Art) in ihren Passwörtern zulässt: Nur [a-Z 1-9]. Gibt es einen triftigen Grund dafür? Es scheint kontraproduktiv zu sein, die Kennwortstärke wie diese zu bremsen, insbesondere für ein System, das solche wertvollen Informationen schützt.

Das einzige, was ich finden konnte, ist ein schwacher Versuch, SQL-Injektionen zu vereiteln, aber das würde Angenommen, die Passwörter werden nicht gehasht (was hoffentlich nicht stimmt).

Selbst Verschlüsselung bedeutet nichts zeichenweises, moderne Verschlüsselung arbeitet auf binärer Ebene. Ich werde Sie jedoch Banken und dergleichen betrachten lassen, die nach x-, y- und z-Zeichen aus dem Passwort fragen ...
Mit Sonderzeichen beziehen Sie sich auf ASCII-Sonderzeichen wie `,. / <>?; ':" [] {} \ |! @ # $% ^ & * (- = _ + `oder Unicode-Zeichen` € `,` £ `,` ♥ `wie in der Antwort von p ____ h vorgeschlagen?
Ally Bank empfiehlt keine Sonderzeichen in Ihrem Passwort, wenn Sie über Android auf Ihr Konto zugreifen möchten. Völlig dumm. Zumindest Standardzeichen wie ein? sollte erlaubt sein.
Manchmal kein technischer Grund. Sehen Sie sich diese großartige (und witzige) Antwort auf eine ähnliche Frage zur Kennwortlänge an: http://security.stackexchange.com/questions/33470/what-technical-reasons-are-there-to-have-low-maximum-password- Längen
[Hier ist eine weitere sehr ähnliche Frage auf einer Schwesterseite] (http://programmers.stackexchange.com/questions/87366/are-there-any-valid-reasons-for-disallowing-characters-and-limiting-the-length- Ö)
Plot Twist: Auf jeder Website verwende ich das gleiche Passwort, das ich für stark halte, weil es Symbole enthält, mit den Zeichen "$", "=" und "@".Ihre Bank hat mich nur daran gehindert, überall dasselbe Passwort zu verwenden.
Zehn antworten:
#1
+67
Mark Burnett
2012-07-17 01:19:24 UTC
view on stackexchange narkive permalink

Eine Erklärung, die ich hier nicht gesehen habe, ist, dass viele Finanzinstitute eng in ältere Systeme integriert sind und an die Einschränkungen dieser Systeme gebunden sind.

Die Ironie dabei ist, dass ich Systeme gesehen habe, die wurden gebaut, um mit älteren Systemen kompatibel zu sein, aber jetzt sind die älteren Systeme weg und die Richtlinie muss noch vorhanden sein, um mit dem neueren System kompatibel zu sein, das gebaut wurde, um mit dem älteren System kompatibel zu sein.

(Die Lektion hier lautet: Wenn Sie mit einem alten System kompatibel sein müssen, sollten Sie diese Einschränkungen in Zukunft beseitigen.)

Dies ist ein großes Sicherheitsproblem. +1 für den Hinweis auf einen der größten Mängel in der IT-Sicherheit, zumindest meiner Meinung nach.
Dies bedeutet natürlich, dass die Passwörter nicht in einem Hash-Format gespeichert sind. Wenn sie gehasht würden, wären auch ältere Systeme kein Problem.
Das ist wahrscheinlich ein guter Teil der Erklärung ... es ist ironisch und traurig.
#2
+13
p____h
2012-07-14 03:20:54 UTC
view on stackexchange narkive permalink

Was ist mit den Supportkosten? Nehmen wir an, wir haben jedem erlaubt, ein Passwort zu erstellen, das aus Zeichen besteht. Hurra, wir können Sonderzeichen in unseren Passwörtern verwenden. Aber warten Sie - wie um alles in der Welt können wir dieses Passwort eingeben, wenn wir über das Mobiltelefon auf unsere Bank zugreifen möchten? Es ist einfacher, über unsere Tastatur als über das Mobiltelefon einzugeben.

Was ist mit Feiertagen? Wir sind in Großbritannien, die nur auf die UK-Tastatur zugreifen. Anstelle von können wir einfach £ eingeben. Das Wort leicht ist hier sehr wichtig. Für einige durchschnittliche Benutzer kann es ein Problem sein, die Zeichen für die "neue" Tastatur einzugeben. Wie wird er versuchen, es zu lösen? Er wird wahrscheinlich den Bank-Support anrufen, um ihn zu bitten, sein Passwort zu ändern oder zu fragen, warum das € -Zeichen von seiner Tastatur verschwunden ist.

Dies ist ohnehin ein Problem. Wie einfach ist es, Ihr englisches Passwort auf einer chinesischen oder arabischen Tastatur einzugeben, da für mein Telefon alle von Ihnen angeforderten Zeichen im britischen Layoutmodus sofort verfügbar sind. Das Umschalten des Layouts auf dem Betriebssystem und das Drücken des gleichen Tastenpaars funktioniert unabhängig von den Markierungen auf den Tastenkappen.
Ich weiß, dass es nur eine Vermutung ist, aber der Typ Benutzer, der nicht herausfinden kann, wie er sein Passwort erneut eingeben soll und glaubt, dass der Schlüssel von der Tastatur "verschwunden" ist, erstellt wahrscheinlich keine cleveren Passwörter mit Sonderzeichen, sondern verwendet solche wie "goldfish2" `.
Absoluter Schwachsinn. Wenn Sie ein Passwort mit beliebigen Zeichen erstellen, sollten Sie sich nur darum kümmern, wie Sie ein solches Passwort erneut eingeben. Es war schließlich Ihre eigene Entscheidung! ** Jede Art von Eingabe sollte als Passwort mit jeder vernünftigen Länge erlaubt sein **, insbesondere bei so wichtigen Dingen wie dem Bankkonto. Wir haben diese Passwörter / Passphrasen sowieso gehasht, es macht absolut keinen Sinn, den Zeichensatz einzuschränken. Es ist ein totaler Wahnsinn.
Eine Einschränkung (ob sie die Verwendung von Sonderzeichen verbietet oder verbindlich macht) erleichtert dem Benutzer die Arbeit nicht. Wenn nichts anderes, werden einige Benutzer nicht in der Lage sein, ihr "normales" Passwort zu verwenden und sie zu zwingen, ein anderes zu erstellen / sich daran zu erinnern (was Sie aus anderen Gründen vielleicht wünschenswert finden, aber es ist objektiv immer noch ärgerlich und als solches nicht "einfach").
Dies ist der einzige Grund, warum ich nicht versucht habe, meine Passwörter in 私 は 何 か und andere Nicht-ASCII-Varianten zu ändern. Ich kann nicht garantieren, dass ich es überall eingeben kann
@hijarian Leider ist das, was Sie dort schreiben, ein sehr unbeliebter PR-Slogan.Wir können den ganzen Tag über Sicherheitsideale streiten, aber wenn sich der Benutzer am Ende des Tages nicht auf seinem Bankkonto anmelden kann, hat das System nicht das getan, was es sollte.Ist dies ein guter Grund, die druckbaren ASCII-Zeichen auf fast jeder Tastatur weltweit einzuschränken?Nein. Ist dies ein guter Grund, um zu verhindern, dass Benutzer Unicode verwenden?Könnte sein
@DreamConspiracy "Unicode zulassen" ist nicht dasselbe wie "Unicode erzwingen".Wenn es Sie persönlich nicht interessiert, verwenden Sie einfach 7-Bit-ASCII, ich bin was, dagegen irgendwie? Eines der Ziele eines guten Passworts ist es, es einem Cracker zu erschweren, es zu erraten oder noch besser zu reproduzieren.Wenn ich nur ein einzelnes Zeichen außerhalb von Unicode BMP einfüge, ist mein Kennwort für eine gängige Bruteforce- / Wörterbuchsoftware grundsätzlich nicht mehr zu ermitteln.Ich bin absolut bereit, mir Unannehmlichkeiten zu bereiten, wenn ich einen Weg finde, diesen Charakter für diese Sicherheitsstufe einzugeben.Ich weiß aber nicht, ob es ein guter PR-Slogan ist.
@hijarian Mein Kommentar wurde nicht geschrieben, weil Sie sich Sorgen machen und Ihr Passwort eingeben können.Es wurde geschrieben, weil Millionen anderer Benutzer den Unterschied zwischen druckbaren ASCII und Unicode nicht einmal kennen und leiden werden, weil das System es ihnen erlaubt hat, den Fehler der Verwendung von Unicode-Zeichen zu machen.Dies ist besonders relevant, da Sie nicht aufgefordert werden, die Sicherheit in der realen Welt zu opfern: Wenn Sie ein Kennwort verwenden, das vom Kennwortmanager mit hoher Entropie generiert wurde, benötigen Sie nicht einmal nicht alphanumerische Zeichen, um mehr als 150 Entropiebits zu erhalten.
@DreamConspiracy Wiederum war mein Punkt von Anfang an diese Kombination von Wörtern, die Sie verwenden: "wird leiden, weil das System ihnen erlaubt hat, den Fehler der Verwendung von Unicode-Zeichen zu machen".Aus irgendeinem Grund denken Sie an das System, das die Verwendung von Unicode-Zeichen als etwas Schlechtes erlaubt.Wenn der Benutzer das Unicode-Zeichen an erster Stelle eingeben könnte, hätte er vielleicht die Möglichkeit, es in Zukunft erneut einzugeben, nein?Was fehlt mir, damit es nicht wahr ist?Lassen Sie uns nach dieser Logik auch den Unicode in Benutzernamen verbieten, einschließlich der E-Mail-Adressen - dasselbe Problem gilt auch für sie.
@ewanm89 FYI: Es gibt keine "chinesische Tastatur".Eine Tastatur, die Chinesisch eingeben kann, ist immer noch eine Tastatur mit 26 Alphabet-Tasten und 10 Zifferntasten sowie Umschalt- und Strg-Tasten usw.Es ist meistens, wenn nicht immer, die Software-Eingabemethode, nicht die Hardware, die Ihre Sprache bestimmt.Und Betriebssysteme (oder IME) lassen Sie normalerweise nicht einmal in eine nicht-lateinische Sprache wechseln, wenn Sie Kennwörter eingeben.
@SOFe nicht ganz genau, aber ich werde zustimmen, dass sie nicht üblich oder Standard sind. Es gibt Prototypen von riesigen Tastaturen mit vielen Schaltflächen: https://upload.wikimedia.org/wikipedia/commons/4/4f/Large_chinese_keyboard.jpg Der Punkt ist, dass Sprachen und Eingabemethoden so unterschiedlich sind, dass man sich nicht sicher sein kann.
Es gibt Zehntausende von chinesischen Schriftzeichen.Sie können nicht einmal alle auf zwei Wörterbuchseiten drucken.
#3
+12
D Coetzee
2012-07-16 01:13:06 UTC
view on stackexchange narkive permalink

Dies kann (schwach) als Tiefenverteidigungsmaßnahme gerechtfertigt sein. Wenn ein Injection- oder anderer Dateninterpretationsfehler vorliegt, kann die Begrenzung des Kennwortzeichensatzes und der Länge möglicherweise verhindern, dass er ausgenutzt werden kann. Dies vereinfacht auch die Implementierung etwas, da die Behandlung von Unicode- und Multibyte-Zeichenfolgen irrelevant ist, wenn sie nur mit 7-Bit-ASCII-Zeichen arbeiten, und einfachere Implementierungen in der Regel weniger Fehler enthalten.

Bewertung Dieses verringerte Risiko gegenüber dem erhöhten Risiko aufgrund der geringeren Kennwortqualität ist nicht einfach. Ich würde erwarten, dass mit zunehmender Anzahl der Benutzer eines Systems auch die Anzahl der Kennwörter zunimmt, die kompromittiert werden könnten, was eine Investition in die Aufhebung solcher Einschränkungen lohnender macht . Trotzdem sind die Passwörter der meisten Benutzer schrecklich, selbst wenn das Feld völlig uneingeschränkt ist.

Ja, oder konvertieren Sie das Kennwort einfach in eine Hex- oder Base64-Codierung, bevor Sie es in der Datenbank speichern ... Das Kennwort ist das wichtigste Sicherheitsmerkmal.Wahrscheinlich sollte es sich lohnen, es richtig zu machen.Ehrlich gesagt, der einzige Teil des Passworts, den die DB sowieso sehen sollte, ist ein Hash, der immer rein binär ist.
#4
+9
dr jimbob
2012-07-14 02:41:09 UTC
view on stackexchange narkive permalink

Ich vermute, dass die Richtlinie für alle vom Benutzer eingegebenen Felder vorhanden ist und dass der Einfachheit halber dieselbe Benutzereingaberichtlinie (keine Sonderzeichen) auf Felder einschließlich Kennwörtern angewendet wurde. Oder irgendwann hatte eine Bank keine Hashing-Passwörter mehr und hatte einen SQLi-Angriff über ihr Passwortfeld. Es wurde entschieden, dass Passwörter keine Sonderzeichen enthalten dürfen (und der Grund für die Richtlinie wurde nach Einführung des Hashing vergessen).

Es ist definitiv ein Sicherheitsvorteil, Sonderzeichen in anderen vom Benutzer eingegebenen Feldern nicht zuzulassen, die nicht gehasht sind und für verschiedene Angriffe wie SQLi oder XSS (bei einem Bankadministrator, der sich ein Konto ansieht) verwendet werden können. Diese Bedrohungen werden jedoch im Allgemeinen gelöst, indem immer gebundene Parameter in SQL verwendet und Benutzereingaben bereinigt werden, bevor sie in db angezeigt / gespeichert werden.

Meine andere Vermutung ist, dass sie benutzerdefinierte Regeln haben möchten, die sich von denen unterscheiden können An anderen Orten können Sie Ihr sicheres Standardkennwort (das möglicherweise verloren geht) nicht einfach wiederverwenden und müssen sich etwas Einzigartiges für ihre Site einfallen lassen.


BEARBEITEN: Abhängig von weiteren Überlegungen In Bezug auf die Sprache kann ich mir mindestens drei ASCII-Sonderzeichen vorstellen, die allgemein verboten / entfernt werden sollten, da sie nur das Schicksal verführen. Insbesondere: \ 0 (null - ascii 0), da es üblicherweise verwendet wird, um das Ende der Zeichenfolge in Sprachen im C-Stil anzuzeigen (möglicherweise müssen Benutzer den Speicher nach dem Ende der Zeichenfolge ändern). Auch Wagenrückläufe und Zeilenvorschübe \ r (ascii 13) und \ n (ascii 10), da diese häufig systemabhängig sind, ob Zeilenumbrüche \ r \ sind n oder \ n und das bringt das Unvermeidliche mit sich, dass ich mich nur unter Windows anmelden kann, nicht unter meinem Mac / Linux-Computer. Tatsächlich erscheint es durchaus sinnvoll, nur druckbare ASCII (32-126) zuzulassen und die nicht druckbaren ASCII 0-31 und 127 zu verbieten.

Aber wenn Sie mit Sonderzeichen Unicode meinen, nicht ASCII-Zeichen (wie ,. / <> ?; ': "[] {} \ |! @ # $% ^ & * (- = _ + Aus Gründen der Einfachheit der Implementierung von mehreren Betriebssystemen / Tastaturen / Browsern erscheint es sinnvoll, keine Sonderzeichen zuzulassen. Stellen Sie sich vor, Ihr Passwort enthält einen Pi in Kleinbuchstaben. War das der griechische pi (π), der Codepunkt 0x3c0, oder der koptische Kleinbuchstabe pi ( ⲡ) Dies ist der Codepunkt 0x2ca1 - nur einer funktioniert, und diese Art von Problem mit ähnlichen Zeichen mit unterschiedlichen Codepunkten tritt im Unicode auf. Ihr Hash, der mit Bits arbeitet, kann die beiden π nicht gleichsetzen. Wenn Sie sich also anmelden An verschiedenen Stellen können Sie unterschiedliche Zeichen eingeben.

Obwohl dieses Problem ein Problem ist, das der Programmierer weitgehend kontrollieren und versuchen kann, es zu korrigieren, führt das Zulassen von Unicode-Zeichen zu Codierungsproblemen. Bei Ihren grundlegenden ASCII-Zeichen wird alles dargestellt in einer Ein-Byte-Zahl. Es gibt jedoch eine Reihe von verschiedenen verschiedene Schemata zum Codieren von Unicode. Ist es UTF-7, UTF-8, UTF-16, UTF-32, Latin-1 (ISO-8859-1), Latin-N-Codierung und (für einige Codierungen) die Bytereihenfolge (Little oder Big Endian)? ? Der Unicode-Codepunkt für pi (0x3c0) würde in UTF-7 als Bytes 2b 41 38 41 2d , in UTF-8 CF 80 als FF FE c0 dargestellt 03 in UTF-16 und FF FE 00 00 c0 03 00 00 in UTF-32. Sie könnten pi nicht in Latein-1 darstellen (es enthält nur 95 zusätzliche druckbare Zeichen), aber wenn Sie ein A1 in Ihrem Passwort hatten und sich in verschiedenen Codierungen befanden, müssen Sie es möglicherweise darstellen von einem der folgenden Zeichen ¡ĄĦЁ 'ก ”Ḃ (was in einigen lateinischen N zu A1 führen kann).

Ja, auf der Webseite ist möglicherweise ein Zeichensatz definiert, aber Benutzer Sie können den Zeichensatz auf einer Seite in ihrem Browser überschreiben oder Daten von einer anderen Stelle in einer anderen Codierung kopieren und einfügen. Am Ende des Tages kann es einfacher sein, diese Zeichen einfach zu verbieten.

Fast jedes Finanzinstitut, das Daten zu Ihren persönlichen Daten und Ihrem Bargeld speichert, wurde einer strengen Sicherheitsüberprüfung unterzogen, die nach jeder wesentlichen Änderung des Systems wiederholt werden sollte. Es ist also schwer, an Informationen aus Ihrem zweiten Absatz zu glauben.
p___h - Ihr Kommentar macht keinen Sinn. Ein Teil eines Sicherheitsaudits sucht nach gebundenen Parametern usw.
@p____h Finanzinstitute sind in der Regel diejenigen, die ihre eigenen Regeln und Vorschriften für die Prüfung aufstellen, und dies sind nicht immer Best Practices. Es liegt auch an ihnen, wenn sie Audits wiederholen.
Sollte es keine Vorschriften geben, wenn diese Institutionen personenbezogene Daten erheben möchten? AFAIK, nicht jeder kann personenbezogene Daten verarbeiten. Sie müssen eine Erlaubnis dafür haben und die Vorschriften befolgen, wenn Sie sie verarbeiten möchten (oder dies hängt möglicherweise vom Land ab).
@p____h - Es heißt [Tiefenverteidigung] (http://en.wikipedia.org/wiki/Defense_in_depth_ (Computing \)) und gilt als bewährte Sicherheitspraxis. Wenn Sie anfangen, Benutzer Benutzerfelder (z. B. einen Kommentar) wie "