Lors de l'enregistrement, de nombreux sites interdisent l'utilisation de symboles dans des mots de passe. Cela me rend le mur à partir d'une perspective de convivialité car j'include plusieurs symboles dans tous mes mots de passe et en tant que programmeur qui traite d'une authentification Web de temps en temps, je ne peux pas comprendre pourquoi il ne serait pas autorisé. Est-ce que je manque quelque chose? Sont-ils inquiets pour l'injection SQL? Vous ne voulez pas traiter avec des personnages qui échappent? Ou y a-t-il quelque chose avec des caractères alphabet non latins qui peuvent gâcher les choses?
Question similaire, à propos des sites qui restreignent la longueur ici . < / p>
11 Réponses :
La paresse ne sonne pas bien. Semble comme le moyen le plus bas de le faire serait de ne pas avoir de validation d'entrée du tout.
Je dois vraiment reculer le commentaire du système hérité. Dans un sens plus général, le stockage de mot de passe pourrait être entravé par certains mécanisme d'authentification 3ème partie. Ne présumez jamais que l'authentification est faite par le site Web lui-même. C'est un fait malheureux d'intégrer avec les systèmes existants.
+1 pour les systèmes hérités et pour les morons paresseux - je soupçonne qu'il y a un mélange là-bas.
"La paresse" comme dans "Nous sommes trop paresseux pour mapper le mot de passe sur quelque chose que le système sous-jacent peut gérer"
Je suis d'accord - à tout moment, je vois un site qui n'aime pas les caractères spéciaux dans les mots de passe ou (pire) a une limite sur le nombre de caractères de votre mot de passe, il me rend toujours un peu méfiant sur la sécurité du site.
Cela signifie probablement qu'ils sont paresseux ou pas très intelligents. Si vous stockez uniquement un hachage, vous n'aurez pas à vous soucier des séries de caractères, des injections ou de l'espace. À peu près ce qui a été expliqué dans cette autre question que vous avez donnée.
C'est une question de broyage des dents, en particulier lorsque les banques le font; Cependant, je pense que certains des problèmes sont avec le ';'; et '' '' 'Personnages.
De retour dans la journée Certains programmeurs, je soupçonnent, pensé en forçant les caractères alphanumériques, que les gens pourraient oublier leurs mots de passe facilement.
mauvaise programmation et le fait qu'ils le stockent dans un texte clair, je suis sûr.
Notre système a une fois dû travailler avec une quincaillerie tierce qui a été exploitée par l'écran tactile. Leur erreur à l'écran .... "clavier", n'a sûrement pas eu de caractères non alphanumériques. Nous avons donc rencontré des problèmes assez graves avec des mots de passe - les clients ont dû les changer.
Même chose avec une panneau £, visitée aux États-Unis, je ne me souvenais pas du code alt pour £
Une raison possible: l'interface utilisateur du site est conçue par un type de marketing ou un responsable de produit non technique. Quelqu'un qui ne comprend pas la combinatoire et pense qu'ils fournissent à leurs développeurs avec des exigences précises en dictant que le champ Mot de passe doit contenir exactement 8 caractères alphanumériques.
Ils ne sont pas aux États-Unis: en Europe, vous avez un clavier différent tous les quelques kilomètres. Bonne chance de trouver votre caractère spécial sur un clavier italien. Ou un grec. Ou turc.
Les seules clés qui sont probablement il y a probablement les clés alphanumériques et la plupart des gens seront capables de se frayer un chemin autour d'eux, même si quelques clés seront échangées (Y et Z, par exemple).
Enfin, les gens sont notoirement mauvais à des mémoires de mots de passe. Les forcer à utiliser "miel" au lieu de "JH (/ & DFA93475" réduit considérablement le taux d'appels de support ("Je ne me souviens pas de mon mot de passe ...")
Si c'est une application Web, les développeurs n'étaient pas vraiment en mesure de s'assurer que les UMLAUTES survivent au transfert de la forme à leur backend. Ce serait formidable si tout le navigateur envoie simplement UTF-8 mais la plupart des backends ne peuvent pas gérer UTF-8 sans un réglage prudent, non plus.
Il est possible que le même mot de passe soit saisi via le clavier du téléphone (1 = 1, A, B ou C).
Réalisant que ceci est terriblement insécurisé, une manière d'augmenter la sécurité serait de verrouiller le compte après X Mauvaise tentatives de mot de passe. Souvent, des sites Web de banque ne sont qu'une extrémité avant pour une application centrale horriblement ancienne et ne peut pas modifier les stratégies de mot de passe.
La raison pour laquelle ils ont besoin alphanumérique est généralement une tentative d'empêcher l'injection SQL lorsque des mots de passe sont entrés. Par exemple:
sur certains sites, vous pouvez réellement saisir: U: admin P: 'ou' t '=' t
Normalement les programmeurs remontent à cela en utilisant des pratiques de programmation telles que SQL paramétrés, mais je suis prêt à parier c'est pourquoi ils le font.
Je ne peux pas dire s'il est vrai pour de nombreux sites Web, mais dans de nombreux environnements de réseau antiquités utilisant un rayon ou une autre forme d'authentification centralisée, vous devez souvent restreindre vos mots de passe au dénominateur commun le plus bas pour tous les systèmes disparates que vous soutenez. Donc, si vous soutiendrez l'authentification par mot de passe pour une application héritée mal écrite qui pose des problèmes avec des caractères non-ASCII et que ce serveur tirant sur le serveur d'authentification central, vous êtes obligé de limiter tous les autres serveurs aux mêmes restrictions de mot de passe.
Les applications auraient pu avoir eu des problèmes d'injection SQL dans les programmeurs passés et trop zélés, juste désactivé tous les ASCII au lieu de traiter les défauts fondamentaux de leur conception.
Les développeurs peuvent vouloir minimiser les problèmes avec des données binaires sinquant un service de mot de passe et sont trop zélés dans leur validation de données. Honnêtement, je pense que c'est le scénario le plus probable. Les programmeurs ont peut-être déjà suivi une approche ASCII uniquement des noms d'utilisateur et viennent d'étendre la même ligne de réflexion aux mots de passe.
S'ils ne trouvent pas votre mot de passe choisi dans leur dictionnaire, comment peuvent-ils dire si vous utilisez un mot de passe assez fort? ;)