it-swarm-eu.dev

Warum Sonderzeichen in einem Passwort nicht zulassen?

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 erscheint kontraproduktiv, die Kennwortstärke wie diese zu bremsen, insbesondere für ein System, das solche wertvollen Informationen schützt.

Das einzige, was ich mir einfallen lassen konnte, ist ein schwacher Versuch, SQL-Injektionen zu vereiteln, aber das würde voraussetzen, dass die Passwörter nicht gehasht werden (was ich sicher hoffe, dass es nicht stimmt).

68
Gary

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 so gebaut wurden, dass sie mit älteren Systemen kompatibel sind, aber jetzt sind die älteren Systeme weg und die Richtlinie muss noch vorhanden sein, um mit dem neueren System kompatibel zu sein, das so gebaut wurde, dass es mit dem älteren System kompatibel ist.

(Die Lehre hier ist, dass Sie, wenn Sie mit einem alten System kompatibel sein müssen, diese Einschränkungen in Zukunft beseitigen können).

65
Mark Burnett

Was ist mit den Supportkosten? Nehmen wir an, wir haben jedem erlaubt, ein Passwort zu erstellen. Es besteht aus Zeichen. 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 vom Mobiltelefon aus Zugang zu unserer Bank erhalten möchten? Es ist einfacher, von unserer Tastatur als vom Handy.

Was ist mit Urlaub? Wir sind in Großbritannien, die nur auf die UK-Tastatur zugreifen. Anstatt von wir können leicht £. Das Wort easily ist hier sehr wichtig. Für einige durchschnittliche Benutzer könnte 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 why the € character dissapeared from his keyboard.

13
p____h

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

Es ist jedoch nicht einfach, dieses verringerte Risiko anhand des erhöhten Risikos aufgrund der geringeren Kennwortqualität zu bewerten. 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 Kennwörter darstellt Einschränkungen lohnen sich mehr. Trotzdem sind die Passwörter der meisten Benutzer schrecklich, selbst wenn das Feld völlig uneingeschränkt ist.

12
D Coetzee

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, und es wurde entschieden, dass Passwörter keine Sonderzeichen enthalten dürfen (und der Grund für die Richtlinie wurde vergessen, als das Hashing eingeführt wurde).

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 verwendet werden können (bei einem Bankadministrator, der sich ein Konto ansieht). 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 möglicherweise von anderen Orten unterscheiden, sodass Sie Ihr sicheres Standardkennwort (das möglicherweise verloren geht) nicht einfach wiederverwenden können und sich etwas Einzigartiges für ihre Website einfallen lassen müssen.


EDIT: Bei weiteren Überlegungen kann ich mir je nach Sprache mindestens drei Sonderzeichen vorstellen ASCII Zeichen, die allgemein verboten/entfernt werden sollten, da sie nur das Schicksal verführen. Insbesondere: \0 (null - ascii 0), da es normalerweise verwendet wird, um das Ende der Zeichenfolge in Sprachen im C-Stil anzugeben (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 oft systemabhängig sind, ob Zeilenumbrüche \r\n oder \n sind, und das bringt das Unvermeidliche hervor, dass ich mich nur anmelden kann von Windows nicht von meinem Mac/Linux-Computer. Tatsächlich scheint es durchaus vernünftig, nur druckbare ASCII (32-126) zuzulassen und die nicht druckbare ASCII 0) zu verbieten -31 und 127.

Wenn Sie jedoch mit Sonderzeichen Unicode nicht ASCII Zeichen (wie ,./<>?;':"[]{}\|[email protected]#$%^&*(-=_+) Meinen, erscheint es aus Gründen der Einfachheit der Implementierung von mehreren Betriebssystemen/Tastaturen/Browsern sinnvoll, Sonderzeichen nicht zuzulassen. Stellen Sie sich vor Ihr Passwort hatte einen Kleinbuchstaben pi. War das der griechische pi (π), der Codepunkt 0x3c0 ist, oder der koptische Kleinbuchstabe pi (ⲡ), der Codepunkt 0x2ca1 ist - nur einer wird funktionieren und diese Art von Problem mit ähnlichen Zeichen mit unterschiedlichen Codepunkten wird in Unicode existieren. Ihr Hash, der mit Bits arbeitet, kann die beiden π nicht gleichsetzen. Wenn Sie also versuchen, sich an verschiedenen Stellen anzumelden, können Sie verschiedene Zeichen eingeben.

Auch wenn es sich um ein Problem handelt, das der Programmierer weitgehend kontrollieren und versuchen kann, es zu korrigieren, führt das Zulassen von Unicode-Zeichen zu Codierungsproblemen. Das heißt, für Ihre grundlegenden ASCII-Zeichen wird alles in einer 1-Byte-Zahl dargestellt. Es gibt jedoch eine Reihe verschiedener 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 als CF 80, In UTF-16 als FF FE c0 03 Und FF FE 00 00 c0 03 00 00 In UTF-32. Sie könnten pi nicht in Latein-1 darstellen (es hat nur 95 zusätzliche druckbare Zeichen), aber wenn Sie ein A1 In Ihrem Passwort hatten und in verschiedenen Codierungen waren, müssen Sie es möglicherweise von jedem darstellen der folgenden Zeichen ¡ĄĦЁ‘ก”Ḃ (was in einigen lateinischen N zu A1 kann).

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

9
dr jimbob

Als Verallgemeinerung sind hier die häufigsten Gründe aufgeführt, warum Finanzinstitute die Länge und die Komplexität von Zeichensätzen einschränken.

(1) Die Webdienste sind Front-End-Systeme für ältere Mainframe-Anwendungen, die häufig eine Beschränkung von acht Zeichen aufweisen, die nur aus Kleinbuchstaben und Zahlen besteht. Keine "Sonderzeichen". Seltsamerweise ist dies die häufigste Einschränkung. +1 an Mark Burnett oben.

(2) Sie haschen die Passwörter nicht, daher können sie nicht einfach eine numerische Zeichenfolge fester Länge speichern (d. H. Die Hash-Ausgabe - 32 Bytes SHA256 (Passwort)). Als solche müssen sie sich darum kümmern, die Größe der Eingabe zu begrenzen.

(3) Der SQL-Injection-Bedrohungsvektor ist nur dann ein Kennwortproblem, wenn die Kennwörter als Klartext gespeichert sind. Viele Organisationen und andere verschwenden Zeit damit, sich die Zeichen des Kennworts zu entziehen, wenn das Problem sofort durch Speichern eines gehashten Kennworts behoben wird (idealerweise gesalzen und gedehnt mit so etwas wie PBKDF2).

Abgesehen von der Bevorzugung eines einfachen Zurücksetzens des Kundensupportkennworts über die Sicherheit gibt es keinen akzeptablen Grund, den ich kenne, um ein Benutzerkennwort im Klartext vom Gerät des Benutzers zu übertragen. Sie wollen die Haftung nicht, also akzeptieren Sie sie niemals. Dafür sind Krypto-Hashes gedacht.

Hier ist ein großartiger Blog-Beitrag, der einige der Best Practices zusammenfasst und Codebeispiele enthält. http://crackstation.net/hashing-security.htm

4
OnTheShelf

Ich habe tatsächlich einen großen Webshop danach gefragt (bol.com, nicht sicher, ob sie international sind).

Ihr Rat ist, ein sicheres Passwort zu verwenden, es häufig zu ändern, Buchstaben und Zahlen zu verwenden, dass es lang sein sollte, und vielleicht einige andere Dinge, die ich vergessen habe. Wie auch immer, der übliche Rat, dass niemand folgt. Aber sie scheinen sich um die Passwortrichtlinie zu kümmern.

Die meisten Sonderzeichen sind jedoch nicht zulässig, und die maximale Kennwortlänge beträgt 12 Zeichen. Auf Nachfrage sagten sie mir, dass sonst zu viele Leute den Support kontaktieren würden.

Als ich sie zurückschickte, um zu fragen, was das "Passwort vergessen?" Feature war für, ich habe keine Antwort bekommen ...

Für Banken, bei denen ein einfaches Zurücksetzen des Passworts per E-Mail nicht in Frage kommt, sind die Supportkosten wahrscheinlich der Grund (wie von anderen hier vorgeschlagen). Für jede andere Website wie diese bol.com würde ich sehr misstrauen, ob sie ihre Passwörter hasht. Sie sollten dort ein eindeutigeres Kennwort verwenden, wenn die Datenbank leckt, wird Ihr Kennwort bekannt.

2
Luc

Durch die Beschränkung des Zeichensatzes auf alphanumerische Zeichen wird die Wahrscheinlichkeit begrenzt, dass ein Skript oder ein Exploit die Phase der Eingabevalidierung überschreitet.

Der Benutzer kann seine Sicherheit jederzeit durch die Verwendung längerer Kennwörter verbessern. Die Anwendung muss jedoch über eine bestimmte Whitelist verfügen, um Angriffe zu verhindern.

1
Rory Alsop

Ich kann versuchen, meine Sicht auf das obige Problem als UI-Schnittstellendesigner und nicht als Programmierer zu geben: Der entscheidende Punkt hierbei ist, dass die Anmeldeanforderung teilweise ein Problem beim Design der UI-Schnittstelle und kein Problem nur bei der Programmierung ist.

Es gibt ein ausgezeichnetes Buch "Apress - User Interface Design for Programmers", das ein analoges Problem im Zusammenhang mit Fenstergrößen zeigt, das ich unten veröffentlichen werde:

Hier ist ein allgemeines Gedankenmuster für Programmierer: Es gibt nur drei Zahlen: 0, 1 und n. Wenn n erlaubt ist, sind alle n gleich wahrscheinlich. Dieses Gedankenmuster stammt aus der alten Codierungskonvention (wahrscheinlich intelligent), dass Sie außer 0 und 1 keine numerischen Konstanten in Ihrem Code haben sollten.

Jetzt ist das obige Denken bei einem Programmierproblem richtig, aber da es sich um Benutzeroberflächen und insbesondere Windows handelt, ist dies nicht der Fall

Aber es ist nicht wahr. Wie sich herausstellt, ist es nicht gleich wahrscheinlich. Es gibt viele gute Gründe, warum Sie ein Fenster genau am oberen Bildschirmrand wünschen (es maximiert die Bildschirmfläche), aber es gibt wirklich keine Gründe, zwei Pixel zwischen dem oberen Bildschirmrand und dem oberen Bildschirmrand zu lassen . In Wirklichkeit ist 0 also viel wahrscheinlicher als 2.

Wenn wir nun zu unserem Problem kommen, sollten theoretisch alle Zeichen aus programmtechnischer und formaler Sicht gleich wahrscheinlich und gleichermaßen zulässig sein. Hier befinden wir uns jedoch auch in einer UI-Schnittstellenprobleminstanz, und wir müssen uns dessen bewusst sein und ihr das richtige Gewicht geben .

Also werde ich eine Antwort aus dem Thread umschreiben, die meiner Meinung nach richtig ist:

Nehmen wir an, wir haben jedem erlaubt, Passwörter zu erstellen, die das € -Zeichen enthalten. 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 Zugang zu unserer Bank erhalten möchten? Es ist einfacher, € über unsere Tastatur als über das Mobiltelefon einzugeben.

Dies ist aus Sicht der Benutzerfreundlichkeit der Hauptpunkt, und wir sollten dem Benutzer keine Schuld geben, wenn er einige Jahre später mit einem Smartphone feststellt, dass er Jahre zuvor einen Charakter verwendet hat, den er vermeiden sollte.

Es ist unsere Verpflichtung, über diese Art von Problemen nachzudenken und den Benutzer sie vermeiden zu lassen!

0
dendini

Ein wenig zu spät zur Party - ich habe kürzlich gelesen, dass der Grund dafür ist, dass für viele Banken der Wert der erhöhten Sicherheit, diese Zeichen zuzulassen, durch die Implementierungskosten und die Supportkosten für den Umgang mit Kunden aufgewogen wird, die sich nicht an ihre Passwörter erinnern können .

Ich sage nicht, dass es ein guter Grund ist, aber so habe ich interpretiert, was ich gelesen habe.

http://www.theglobeandmail.com/technology/digital-culture/why-canadas-banks-have-weaker-passwords-than-Twitter-or-google/article18325257/

0
Steve Campbell