Question:
Pourquoi interdire les caractères spéciaux dans un mot de passe?
Gary
2012-07-14 01:09:30 UTC
view on stackexchange narkive permalink

Le coupable dans ce cas est une banque particulière (et particulièrement grande) qui n'autorise pas les caractères spéciaux (de quelque sorte que ce soit) dans leurs mots de passe: juste [a-Z 1-9]. Y a-t-il une raison valable de faire cela? Il semble contre-productif de ralentir la force des mots de passe comme celui-ci, en particulier pour un système protégeant des informations aussi précieuses.

La seule chose que j'ai pu trouver est une faible tentative de contrecarrer les injections SQL, mais cela supposons que les mots de passe ne sont pas hachés (ce que j'espère n'est pas vrai).

même le cryptage ne signifie rien du point de vue des caractères, le cryptage moderne opère au niveau binaire. Cependant, je vous laisse considérer les banques et autres qui demandent les caractères x, y et z du mot de passe ...
Par caractères spéciaux, faites-vous référence aux caractères spéciaux ASCII comme `,. / <> ?; ':" [] {} \ |! @ # $% ^ & * (- = _ + `ou aux caractères unicode` € `,` £ `,` ♥ `comme le suggérait la réponse de p ____ h?
Ally Bank ne recommande pas de caractères spéciaux dans votre mot de passe si vous allez accéder à votre compte via Android. Complètement stupide. Au moins des caractères standard comme un? devrait être permis.
Parfois, aucune raison technique. Voir cette excellente réponse (et hilarante) à une question similaire sur la longueur du mot de passe: http://security.stackexchange.com/questions/33470/what-technical-reasons-are-there-to-have-low-maximum-password- longueurs
[Voici une autre question très similaire sur un site jumeau] (http://programmers.stackexchange.com/questions/87366/are-there-any-valid-reasons-for-disallowing-characters-and-limiting-the-length- o)
Plot twist: Sur chaque site Web, j'utilise le même mot de passe Je-pense-qu'il-est-fort-parce-qu'il-a-symboles avec un caractère `` $ `,` = `et` @ `Votre banque m'a simplement empêché d'utiliser le même mot de passe partout.
Dix réponses:
#1
+67
Mark Burnett
2012-07-17 01:19:24 UTC
view on stackexchange narkive permalink

Une explication que je n'ai pas vue ici est que de nombreuses institutions financières sont étroitement intégrées aux systèmes plus anciens et sont liées aux limites de ces systèmes.

L'ironie de ceci est que j'ai vu des systèmes qui ont été conçus pour être compatibles avec les systèmes plus anciens, mais maintenant les anciens systèmes ont disparu et la politique doit toujours exister pour la compatibilité avec le système plus récent qui a été conçu pour être compatible avec l'ancien système.

(la leçon ici est que si vous devez être compatible avec un ancien système, prévoyez une certaine élimination future de ces limitations).

C'est un problème majeur de sécurité. +1 pour avoir signalé l'une des plus grandes failles de la sécurité informatique, du moins à mon avis.
Bien entendu, cela signifie que les mots de passe ne sont pas stockés dans un format haché. S'ils étaient hachés, même les systèmes plus anciens ne seraient pas un problème.
C'est probablement une bonne partie de l'explication ... c'est ironique et triste.
#2
+13
p____h
2012-07-14 03:20:54 UTC
view on stackexchange narkive permalink

Qu'en est-il des frais de support? Disons que nous avons autorisé quiconque à créer un mot de passe composé de caractères . Hourra, nous pouvons utiliser des caractères spéciaux dans nos mots de passe. Mais attendez - comment diable pouvons-nous taper ce mot de passe si nous voulons accéder à notre banque à partir du téléphone portable? Il est plus facile de taper à partir de notre clavier qu'à partir du téléphone portable.

Et les vacances? Nous sommes au Royaume-Uni, qui n'accèdent qu'au clavier britannique. Au lieu de , nous pouvons facilement taper £ . Le mot facilement est ici très important. Pour certains utilisateurs moyens, typer ces caractères pour le "nouveau" clavier peut être un problème. Comment va-t-il essayer de le résoudre? Il appellera probablement le support bancaire pour leur demander de changer son mot de passe ou demander à pourquoi le caractère € a disparu de son clavier .

C'est un problème de toute façon, comme il est facile de taper votre mot de passe anglais sur un clavier chinois ou arabe, comme pour mon téléphone, tous les caractères que vous avez demandés sont immédiatement accessibles en mode disposition britannique. Changer la disposition sur le système d'exploitation et appuyer sur la même paire de touches fonctionne quels que soient les marquages ​​sur les majuscules des touches.
Je sais que ce n'est qu'une conjecture, mais le type d'utilisateur qui ne sait pas comment retaper son mot de passe et croit que la clé "a disparu" du clavier ne crée probablement pas de mots de passe intelligents avec des caractères spéciaux, mais en utilisant des mots comme `goldfish2 ».
Des conneries absolues. Si vous créez un mot de passe avec des caractères arbitraires, c'est seulement _vous_ qui devez vous soucier de la façon de retaper un tel mot de passe. C'était votre propre décision après tout! ** Tout type d'entrée doit être autorisé en tant que mot de passe, avec une longueur raisonnable **, en particulier avec des éléments aussi importants que le compte bancaire. De toute façon, nous hachons ces mots de passe / phrases de passe, il est absolument inutile de restreindre le jeu de caractères. C'est une folie totale.
Une restriction (qu'elle interdise l'utilisation de caractères spéciaux ou les rend obligatoires) ne facilite pas les choses pour l'utilisateur. Si rien d'autre, cela rendra certains utilisateurs incapables d'utiliser leur mot de passe «habituel» et les forcera à en créer / se souvenir d'un autre (ce que vous pourriez trouver souhaitable pour d'autres raisons, mais c'est toujours objectivement ennuyeux et en tant que tel pas «facile»).
C'est la seule raison pour laquelle je n'ai pas essayé de changer mes mots de passe en 私 は 何 か et d'autres variantes non ASCII. Je ne peux pas garantir que je pourrai le saisir partout où j'en aurai besoin
@hijarian, malheureusement, ce que vous y écrivez est un slogan de relations publiques très impopulaire.Nous pouvons discuter des idéaux de sécurité toute la journée, mais à la fin de la journée, si l'utilisateur ne peut pas se connecter à son compte bancaire, le système n'a pas réussi à faire ce qu'il était censé faire.Est-ce une bonne raison pour restreindre les caractères ASCII imprimables trouvés sur presque tous les claviers dans le monde?Non. Est-ce une bonne raison pour empêcher les gens d'utiliser Unicode?Peut être
@DreamConspiracy "Autoriser à utiliser Unicode" n'est pas la même chose que "forcer à utiliser Unicode".Si vous ne vous en souciez pas personnellement, utilisez simplement ASCII 7 bits, je suis quoi, contre cela en quelque sorte? L'un des objectifs d'un bon mot de passe est de rendre plus difficile pour un pirate de le deviner, ou mieux encore, de le reproduire.Si j'insère un seul caractère en dehors d'Unicode BMP, mon mot de passe devient fondamentalement impossible à deviner pour un logiciel de bruteforce / dictionnaire commun.Je suis tout à fait prêt à me déranger en trouvant un moyen de taper ce personnage pour ce niveau de sécurité.Je ne sais pas si c'est un bon slogan de relations publiques.
@hijarian mon commentaire n'a pas été écrit en raison de votre inquiétude et de votre capacité à taper votre mot de passe.Il a été écrit à cause des millions d'autres utilisateurs qui ne connaissent même pas la différence entre ascii imprimable et unicode et qui en souffriront parce que le système leur a permis de faire l'erreur d'utiliser des caractères unicode.Ceci est particulièrement pertinent car ce n'est pas comme si cela vous demandait de sacrifier toute sécurité dans le monde réel: si vous utilisez un mot de passe à entropie élevée généré par un gestionnaire de mots de passe, vous n'avez même pas besoin de caractères non alphanumériques pour obtenir plus de 150 bits d'entropie.
@DreamConspiracy Encore une fois, mon argument depuis le début était cette combinaison de mots que vous utilisez: "souffrira parce que le système leur a permis de faire l'erreur d'utiliser des caractères unicode".Pour une raison quelconque, vous pensez que le système autorise l'utilisation de caractères Unicode comme quelque chose de mauvais.Si l'utilisateur _pouvait entrer le caractère unicode en premier lieu_, peut-être qu'il a le moyen de le saisir à nouveau dans un futur, non?Qu'est-ce que je manque pour que ce ne soit pas vrai?Aussi, par cette logique, interdisons également l'unicode dans les noms d'utilisateur, puis, y compris les adresses e-mail - le même problème s'applique à eux aussi.
@ewanm89 FYI: Il n'existe pas de "clavier chinois".Un clavier qui peut taper le chinois est toujours un clavier avec 26 boutons alphabétiques et 10 boutons numériques et shift et ctrl et ainsi de suite.C'est principalement, sinon toujours, la méthode de saisie logicielle, et non le matériel, qui détermine votre langue.Et les systèmes d'exploitation (ou l'IME) ne vous permettent généralement même pas de passer à une langue non latine lors de la saisie de mots de passe.
@SOFe pas tout à fait précis, mais je conviendrai qu'ils ne sont ni courants ni standards, il existe des prototypes de vastes claviers avec beaucoup de boutons: https://upload.wikimedia.org/wikipedia/commons/4/4f/Large_chinese_keyboard.jpg Le fait est que les langues et les méthodes de saisie varient tellement que l'on ne peut pas en être sûr.
Il existe des dizaines de milliers de caractères chinois.Vous ne pouvez même pas tous les imprimer sur deux pages de dictionnaire.
#3
+12
D Coetzee
2012-07-16 01:13:06 UTC
view on stackexchange narkive permalink

Cela peut être (faiblement) justifié comme une mesure de défense en profondeur - s'il y a une injection ou un autre bogue d'interprétation des données, limiter le jeu de caractères et la longueur du mot de passe peut empêcher son exploitation. Cela simplifie également quelque peu l'implémentation, car s'ils ne traitent que des caractères ASCII 7 bits, la gestion des chaînes de caractères Unicode et multi-octets n'est pas pertinente, et les implémentations plus simples sont généralement moins susceptibles de contenir des bogues.

Cependant, l'évaluation cette diminution du risque par rapport au risque accru dû à une qualité de mot de passe inférieure n'est pas simple - je m'attendrais à ce que, à mesure que le nombre d'utilisateurs d'un système augmente, le nombre de mots de passe susceptibles d'être compromis augmente également, ce qui rend un investissement dans la levée de ces restrictions plus intéressant . Cela dit, les mots de passe de la plupart des utilisateurs seront terribles même si le champ est totalement illimité.

Ya, ou convertissez simplement le mot de passe en encodage hexadécimal ou base64 avant de le stocker dans la base de données ... Le mot de passe est la caractéristique de sécurité la plus importante.Cela devrait probablement valoir la peine de le faire correctement.Honnêtement, la seule partie du mot de passe que la base de données devrait voir de toute façon est un hachage qui est toujours purement binaire.
#4
+9
dr jimbob
2012-07-14 02:41:09 UTC
view on stackexchange narkive permalink

Je suppose que la politique existe pour tous les champs saisis par l'utilisateur et que la même politique d'entrée utilisateur (pas de caractères spéciaux) a été appliquée aux champs comprenant des mots de passe pour plus de simplicité. Ou à un moment donné, une banque n'a pas haché les mots de passe et a eu une attaque SQLi via son champ de mot de passe, et une politique a été décidée que les mots de passe ne peuvent pas avoir de caractères spéciaux (et la raison de la politique a été oubliée une fois le hachage introduit).

Il y a certainement un avantage de sécurité à ne pas autoriser les caractères spéciaux dans d'autres champs saisis par l'utilisateur qui ne sont pas hachés et pourraient être utilisés pour diverses attaques comme SQLi ou XSS (sur un administrateur de banque regardant un compte). Cependant, ces menaces sont généralement résolues en utilisant toujours des paramètres liés dans SQL et en nettoyant toujours les entrées utilisateur avant d'afficher / d'enregistrer dans la base de données.

Mon autre hypothèse est qu'ils veulent avoir des règles personnalisées qui peuvent être différentes de d'autres endroits, de sorte que vous ne pouvez pas facilement réutiliser votre mot de passe standard fort (qui peut se perdre), et devez trouver quelque chose d'unique pour leur site.


EDIT: Après réflexion, selon sur la langue, je peux penser à au moins trois caractères ASCII spéciaux qui devraient être universellement interdits / supprimés car leur permettant seulement de tenter le destin. Plus précisément: \ 0 (null - ascii 0), car il est habituellement utilisé pour indiquer la fin de la chaîne dans les langages de style C (éventuellement les utilisateurs pour modifier la mémoire après la fin de la chaîne). Également les retours chariot et les sauts de ligne \ r (ascii 13) et \ n (ascii 10), car ils dépendent souvent du système si les sauts de ligne sont \ r \ n ou \ n et cela soulève l'inévitable, je ne peux me connecter qu'à partir de Windows et non de ma machine mac / linux. En fait, il semble tout à fait raisonnable de n'autoriser que les ascii imprimables (32-126) et d'interdire les ASCII 0-31 et 127 non imprimables.

Mais si vous entendez par caractères spéciaux unicode et non des caractères ASCII (comme ,. / <>?; ': "[] {} \ |! @ # $% ^ & * (- = _ + il semble raisonnable pour la simplicité de mise en œuvre à partir de plusieurs systèmes d'exploitation / claviers / navigateurs de ne pas autoriser les caractères spéciaux. Imaginez que votre mot de passe contienne un pi minuscule. Était-ce le grec pi (π) qui est le point de code 0x3c0 ou le pi minuscule copte ( ⲡ) qui est le point de code 0x2ca1 - un seul fonctionnera et ce type de problème de caractères similaires avec des points de code différents existera en unicode. Votre hachage qui fonctionne sur des bits ne pourra pas assimiler les deux π, donc si vous essayez de vous connecter différents endroits où vous pouvez saisir différents caractères.

De même, bien que ce problème soit un problème que le programmeur peut en grande partie contrôler et tenter de corriger, autoriser les caractères unicode crée des problèmes d'encodage. C'est pour vos caractères ascii de base que tout est représenté dans un nombre à un octet. Cependant, il y a un tas de dif schémas différents pour savoir comment encoder unicode. Est-ce le codage UTF-7, UTF-8, UTF-16, UTF-32, Latin-1 (iso-8859-1), Latin-N et (pour certains codages) quel est l'ordre des octets (petit ou gros boutiste) ? Le point de code unicode pour pi (0x3c0) serait représenté par les octets 2b 41 38 41 2d en UTF-7, CF 80 en UTF-8, FF FE c0 03 en UTF-16 et FF FE 00 00 c0 03 00 00 en UTF-32. Vous ne pourriez pas représenter pi en Latin-1 (il ne contient que 95 caractères imprimables supplémentaires), mais si vous aviez un A1 dans votre mot de passe et que vous étiez dans des encodages différents, vous devrez peut-être le représenter à partir de l'un des caractères suivants ¡ก 'ก ”Ḃ (qui dans certains Latin-N peut être A1).

Oui, la page Web peut avoir un jeu de caractères défini, mais les utilisateurs peuvent remplacer le jeu de caractères sur une page de leur navigateur ou avoir copié et collé des données ailleurs dans un encodage différent. À la fin de la journée, il peut être plus simple d'interdire ces personnages.

Presque toutes les institutions financières qui stockent des données relatives à vos informations personnelles et à votre argent comptant ont fait l'objet d'un audit de sécurité strict, qui devrait être répété après tout changement important du système. Il est donc difficile de croire aux informations de votre deuxième paragraphe.
p___h - votre commentaire n'a aucun sens. Une partie d'un audit de sécurité recherchera des éléments tels que des paramètres liés, etc.
@p____h Les institutions financières ont tendance à être celles qui établissent leurs propres règles et réglementations à contrôler, et ce ne sont pas toujours les meilleures pratiques. Cela a également tendance à leur appartenir lorsqu'ils répètent des audits.
Ne devrait-il pas y avoir de réglementation lorsque ces institutions souhaitent collecter des données personnelles? AFAIK, tout le monde ne peut pas traiter les données personnelles, vous devez avoir l'autorisation pour cela et suivre les réglementations, lorsque vous souhaitez les traiter (ou peut-être que cela dépend du pays).
@p____h - Il s'appelle [défense en profondeur] (http://en.wikipedia.org/wiki/Defense_in_depth_ (computing \)) et est considéré comme une meilleure pratique de sécurité. Si vous commencez à laisser les gens avoir des champs utilisateur (disons un commentaire) comme `