Pourquoi interdire les caractères spéciaux dans un mot de passe?
Le coupable dans ce cas est une banque particulière (et particulièrement grande) qui n'autorise pas les caractères spéciaux (d'aucune sorte) dans leurs mots de passe: Just [a-Z 1-9]. Leur raison est-elle valable pour le faire? Il semble contre-productif de bloquer la force des mots de passe comme celui-ci, en particulier pour un système protégeant de telles informations précieuses.
La seule chose que j'ai pu trouver est une faible tentative de contrecarrer les injections SQL, mais cela supposerait que les mots de passe ne sont pas hachés (ce qui, j'espère, n'est pas vrai).
Une explication que je n'ai pas vue ici est que de nombreuses institutions financières sont étroitement intégrées aux anciens systèmes 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é construits pour être compatibles avec les anciens systèmes mais maintenant les anciens systèmes ont disparu et la politique doit toujours exister pour la compatibilité avec le nouveau système qui a été construit 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 élimination future de ces limitations).
Et le coût du 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 avoir accès à notre banque depuis le téléphone portable? Il est plus facile de taper € depuis notre clavier que depuis le téléphone portable.
Et les vacances? Nous sommes au Royaume-Uni, qui n'a accès qu'au clavier britannique. Au lieu de € nous pouvons facilement taper £. Le mot easily est très important ici. Pour certains utilisateurs moyens, taper les caractères du "nouveau" clavier pourrait être un problème. Comment tentera-t-il de le résoudre? Il appellera probablement le support bancaire pour leur demander de changer son mot de passe ou demandera why the € character dissapeared from his keyboard.
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, la limitation du jeu de caractères et de la longueur du mot de passe peut empêcher son exploitation. Il 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'a pas d'importance et les implémentations plus simples sont généralement moins susceptibles de contenir des bogues).
Cependant, évaluer ce risque réduit par rapport au risque accru dû à une qualité de mot de passe inférieure n'est pas simple - je m'attendrais à ce que le nombre d'utilisateurs d'un système augmente, le nombre de mots de passe qui pourraient être compromis augmente également, investissant dans la levée de tels restrictions plus valables. Cela dit, la plupart des mots de passe des utilisateurs seront terribles même si le champ est totalement libre.
Je suppose que la politique existe pour tous les champs entrés par l'utilisateur et la même politique d'entrée utilisateur (pas de caractères spéciaux) a été appliquée aux champs, y compris les mots de passe pour plus de simplicité. Ou à un moment donné, une banque ne hachait pas les mots de passe et avait une attaque SQLi via leur 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 qui regarde 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/enregistrer dans db.
Mon autre supposition est qu'ils veulent avoir des règles personnalisées qui peuvent être différentes des autres endroits, donc vous ne pouvez pas facilement réutiliser votre mot de passe fort standard (qui peut se perdre), et vous devez trouver quelque chose d'unique pour leur site.
EDIT: Après réflexion, en fonction de la langue, je peux penser à au moins trois caractères spéciaux ASCII qui devraient être universellement interdits/supprimés comme ne leur permettant que d'attirer le destin. Spécifiquement: \0 (null - ascii 0), car il est généralement 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). Retour chariot et sauts de ligne \r (ascii 13) et \n (ascii 10), car ceux-ci dépendent souvent du système, que les sauts de ligne soient \r\n ou \n et cela évoque 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 d'autoriser uniquement ascii imprimable (32-126) et d'interdire les non-imprimables ASCII 0-31 et 127.
Mais si par caractères spéciaux, vous entendez unicode et non ASCII caractères (comme ,./<>?;':"[]{}\|!@#$%^&*(-=_+ il semble raisonnable que la simplicité de mise en œuvre à partir de plusieurs systèmes d'exploitation/claviers/navigateurs n'autorise pas les caractères spéciaux. Imaginez que votre mot de passe contienne un pi minuscule. Est-ce que le pi grec (π) qui est le point de code 0x3c0 ou le pi copte en minuscules (ⲡ) qui est le point de code 0x2ca1 - un seul fonctionnera et ce type de problème de caractères similaires avec différents points de code existera en unicode. Votre hachage qui fonctionne sur des bits ne pourra pas égaler les deux π, donc si vous essayez de vous connecter à différents endroits, vous pouvez entrer des caractères différents.
De même, bien que ce problème soit un problème que le programmeur peut largement 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, tout est représenté dans un numéro d'un octet. Cependant, il existe un tas de schémas différents pour coder unicode. Est-ce UTF-7, UTF-8, UTF-16, UTF-32, Latin-1 (iso-8859-1), encodage Latin-N et (pour certains encodages) quel est l'ordre des octets (petit ou gros endian) ? 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 seriez pas en mesure de représenter pi en latin-1 (il n'a que 95 caractères imprimables supplémentaires), mais si vous aviez un A1 dans votre mot de passe et dans des codages différents, vous devrez peut-être le représenter à partir de l'un des caractères suivants ¡ĄĦЁ‘ก”Ḃ (qui dans certains Latin-N peut à 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 d'ailleurs dans un codage différent. À la fin de la journée, il peut être plus simple d'interdire ces caractères.
En général, voici les raisons les plus courantes pour lesquelles les institutions financières restreignent la longueur et la complexité des jeux de caractères.
(1) Les services Web sont des systèmes frontaux pour les applications mainframe héritées, qui ont souvent une limitation à huit caractères composée uniquement de petits caractères alpha et numériques. Pas de "caractères spéciaux". C'est curieusement la limitation la plus courante. +1 à Mark Burnett ci-dessus.
(2) Ils ne hachent pas les mots de passe, ils ne peuvent donc pas simplement stocker une chaîne numérique de longueur fixe (c'est-à-dire la sortie de hachage - 32 octets de SHA256 (mot de passe)). En tant que tels, ils doivent se soucier de limiter la taille de l'entrée.
(3) Le vecteur de menace d'injection SQL n'est un problème de mot de passe que si les mots de passe sont stockés en texte clair. De nombreuses organisations et d'autres perdent du temps à craindre d'échapper les caractères du mot de passe, lorsque le problème est immédiatement résolu en stockant un mot de passe haché (idéalement salé et étiré en utilisant quelque chose comme PBKDF2).
En plus de privilégier la réinitialisation du mot de passe du support client simple, la sécurité est supérieure à AUCUNE raison acceptable que je sache pour transmettre un mot de passe utilisateur en texte clair hors de l'appareil de l'utilisateur. Vous ne voulez pas de responsabilité, alors ne l'acceptez jamais. C'est à cela que servent les hachages cryptographiques.
Voici un excellent article de blog qui résume certaines des meilleures pratiques et inclut des exemples de code. http://crackstation.net/hashing-security.htm
En fait, j'ai demandé cela à une grande boutique en ligne (bol.com, je ne sais pas s'ils sont internationaux).
Leur conseil est d'utiliser un mot de passe fort, de le changer fréquemment, d'utiliser des lettres et des chiffres, qu'il devrait être long, et peut-être d'autres choses que j'ai oubliées. Quoi qu'il en soit, le conseil habituel que personne suit. Mais ils semblent se soucier de la politique de mot de passe.
Pourtant, ils n'autorisent pas la plupart des caractères spéciaux et la longueur maximale du mot de passe est de 12 caractères. En leur demandant, ils m'ont dit qu'autrement, trop de gens contacteraient le support.
Quand je les ai renvoyés pour leur demander ce que le message "Mot de passe oublié?" fonctionnalité était pour, je n'ai reçu aucune réponse ...
Donc, pour les banques, où une simple réinitialisation du mot de passe par e-mail est hors de question, je suppose que les frais de support sont vraiment la raison (comme suggéré par d'autres ici). Pour tout autre site Web comme ce bol.com, je me méfierais fortement s'ils hachent leurs mots de passe. Vous devriez y utiliser un mot de passe plus unique, si la base de données fuit, votre mot de passe sera connu.
Limiter le jeu de caractères aux caractères alphanumériques limite la probabilité qu'un script ou un exploit dépasse la phase de validation d'entrée.
L'utilisateur peut toujours améliorer sa sécurité en utilisant des mots de passe plus longs, mais l'application doit avoir une liste blanche spécifique pour aider à prévenir les attaques.
Je peux essayer de donner mon point de vue sur le problème ci-dessus en tant que concepteur d'interface d'interface utilisateur et non en tant que programmeur: le point clé ici est que l'exigence de connexion est en partie un problème de conception d'interface d'interface utilisateur et non un problème de programmation uniquement.
Il y a un excellent livre "Apress - Design d'interface utilisateur pour les programmeurs" qui montre un problème analogue lié aux tailles de fenêtres que je posterai ci-dessous:
Voici un schéma de pensée commun des programmeurs: il n'y a que trois nombres: 0, 1 et n. Si n est autorisé, tous les n sont également probables. Ce schéma de pensée provient de l'ancienne convention de codage (probablement intelligente) selon laquelle vous ne devriez pas avoir de constantes numériques dans votre code, à l'exception de 0 et 1.
Maintenant, la réflexion ci-dessus est correcte dans un problème de programmation uniquement, mais en ce qui concerne les interfaces utilisateur et en particulier les fenêtres, ce n'est pas
Mais ce n'est pas vrai. En fait, il est peu probable. Il existe de nombreuses bonnes raisons pour lesquelles vous pouvez souhaiter une fenêtre exactement en haut de l'écran (cela maximise la surface d'écran), mais il n'y a vraiment aucune raison de laisser deux pixels entre le haut de l'écran et le haut de la fenêtre . Donc, en réalité, 0 est beaucoup plus probable que 2.
Venons-en maintenant à notre problème, théoriquement tous les caractères devraient être également probables et également autorisés d'un point de vue de programmation et formel, mais ici nous sommes également dans une instance de problème d'interface utilisateur et nous devons en être conscients et lui donner le poids correct. .
Je vais donc paraphraser une réponse du fil ci-dessus qui, à mon avis, est correcte:
Disons que nous avons autorisé tout le monde à créer des mots de passe contenant le € char. 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 avoir accès à notre banque depuis le téléphone portable? Il est plus facile de taper € sur notre clavier que sur le téléphone portable.
C'est le principal point de vue de la convivialité et nous ne devrions pas blâmer l'utilisateur s'il se rend compte quelques années plus tard avec un smartphone alors que des années auparavant, il n'existait même pas, qu'il avait utilisé un personnage qu'il aurait dû éviter.
Il est de notre devoir de réfléchir à ce type de problèmes et de laisser l'utilisateur l'éviter!
Un peu tard pour la fête - J'ai récemment lu que la raison en est que pour de nombreuses banques, la valeur de la sécurité accrue de l'autorisation de ces caractères est compensée par le coût de mise en œuvre et le coût de l'assistance pour traiter avec les clients qui ne se souviennent pas de leurs mots de passe .
Je ne dis pas que c'est une bonne raison, mais c'est ainsi que j'ai interprété ce que j'ai lu.