Pourquoi certains sites empêchent-ils les espaces dans les mots de passe?


16

Cela semble moins courant avec les sites Web plus récents, mais de nombreux sites Web sur lesquels j'ai besoin d'un compte (comme pour payer les factures, etc.) m'empêchent de créer un mot de passe avec des espaces. Cela ne fait que rendre les choses plus difficiles à mémoriser , et je ne suis au courant d'aucune restriction de base de données ou de programmation sur les espaces dans les mots de passe, cryptés ou (paradis ne plaise) autrement. Pourquoi, alors, la barre d'espace est-elle si souvent discriminée lorsqu'il s'agit de s'inscrire à un site?


Certains sites peuvent utiliser l'authentification unique, en supposant que l'authentification unique nécessite des mots de passe non vides (pas sûr cependant)!
NoChance

1
Ce qui me fait vraiment peur, c'est lorsque les sites interdisent spécifiquement le devis unique. Quelle raison possible pourriez-vous avoir, si ce n'est d'activer "insert into USERS (..., password) values (..., '" + $POST['password'] + "');" : -S
Christian Klauser

Aurait dû aller à la sécurité, pas aux programmeurs. Cela existe probablement déjà là-bas.
Dan McGrath

Réponses:


20

Il y a énormément de bêtises en ce qui concerne les mots de passe sur les sites Web.

  • Certains ont des raisons purement techniques (valides ou non, c'est une autre question, mais presque toutes ne le sont pas):

Votre mot de passe doit comporter quatre caractères et ne comporter que des chiffres.

(En limitant un mot de passe à la plage 0001 .. 9999, vous pouvez simplement les stocker sous forme de nombre, en clair, dans la base de données)

  • D'autres s'expliquent par des idées erronées selon lesquelles ils rendront les mots de passe plus sûrs :

Votre mot de passe doit commencer par une majuscule et se terminer par un chiffre.

(En faisant cela, le développeur ou le gestionnaire a supposé que cela obligerait les utilisateurs à choisir un mot de passe sûr, tandis que la règle "Votre mot de passe doit contenir au moins 6 caractères et contenir au moins une majuscule, une minuscule et un chiffre "échouera comme par magie)

  • D'autres, enfin, s'expliquent par le fait que les mots de passe sont stockés en texte brut , et qu'il existe certaines ambiguïtés sur la façon dont ils sont stockés, traités ou récupérés, et il n'y a pas de temps pour les tester à l'unité.

Votre mot de passe contient un caractère invalide é.

ou,

Votre mot de passe y$₯46¥*A'xD<7&฿=ᴙcN&sF5_Ở!dcontient des caractères invalides. Utilisez uniquement des caractères de l'alphabet latin et des chiffres.

ou,

Votre mot de passe ne peut pas contenir d'espaces.

Dans les trois cas, le développeur était juste assuré que les mots de passe comme celui-ci seront stockés correctement.

  • Dans le premier cas, que se épassera- t-il si sera transformé en %C3%A9envoi? Ou que faire si la base de données ne stocke épas correctement?

  • Dans le second cas, que se passe-t-il si PHP (pourquoi PHP?) Ne peut pas gérer unicode et fait quelque chose de terrible lors de la réception d'un mot de passe comme celui-ci? Et si le <personnage pose problème? Que faire si le &caractère est interprété comme un séparateur dans une URL (en supposant que pour une raison quelconque, le mot de passe est envoyé via GET au lieu de POST)? Que faire si 'est interprété par la base de données, car, devinez quoi, nous n'avons aucune idée de ce qu'est l'injection SQL et comment l'éviter? Ou si 'se transforme en \'?

  • Dans le troisième cas, que se passe-t-il si PHP (encore?) Coupe les espaces dans certains cas et pas dans d'autres? Que se passe-t-il si les administrateurs (qui ont étonnamment accès aux mots de passe des utilisateurs en texte brut) sont perdus parce qu'ils ne voient qu'un seul espace blanc, alors que l'utilisateur a défini trois espaces blancs consécutifs ?

Dans les trois cas, ces ambiguïtés sont facilement résolues par des tests , en particulier des tests unitaires. Mais dans une énorme quantité de projets, il n'y a pas de test du tout , et pas de temps pour tester (mais toujours beaucoup de temps pour déboguer plus tard).

Cela signifie que si le développeur essaie de réfléchir aux conséquences possibles de l'autorisation d'espaces , de caractères unicode ou de n'importe quel caractère en dehors de ASCII 48..57 ∪ 65..90 ∪ 97..122 (chiffres, lettres minuscules, lettres majuscules) , le moyen le plus simple, lorsque les tests ne sont pas possibles, est de les interdire .

À mon avis, c'est la seule raison d'interdire les espaces. Yannis Rizos a donné une autre raison liée à l'UX. Tout en étant une raison plausible en théorie, cela ne fonctionne pas du tout dans la pratique: les sites Web créés par des personnes qui se soucient réellement de l'UX ne fixent pas de règles de mot de passe stupides. Au lieu de cela, les sites Web où les espaces sont interdits sont en grande partie créés par des personnes qui n'ont jamais entendu parler de l'UX . Cela est particulièrement vrai car interdire tout caractère est vraiment ennuyeux du point de vue UX, comme toute restriction liée au mot de passe, y compris les restrictions utiles, comme le nombre minimum de caractères.


Sans oublier que lorsque vous supprimez des espaces, vous éliminez un tas de mots de passe longs faciles à retenir (et la longueur s'est avérée plus efficace que la complexité contre le craquage) et encouragez les utilisateurs à adopter des mots de passe charabia qui sont beaucoup moins mémorables qu'une longue série. d'espaces.
Lèse majesté

1
Je suis d'accord avec la plupart de ce que j'ai lu, mais j'ai vraiment du mal à digérer la déclaration "de la manière la plus simple, lorsque les tests ne sont pas possibles ...". Test impossible ??? Quiconque accepte un projet où cela se produit: la bêtise est maximisée efficacement ... Oui je sais que ça arrive: - |
Thomas

@Thomas: c'est la différence entre la théorie et la connaissance en général et la pratique avec son ignorance générale et ses contraintes de temps, où beaucoup de gens ne veulent pas perdre de temps à tester, ignorant qu'ils passeront au moins deux fois le débogage plus tard.
Arseni Mourzenko

Il peut être raisonnable d'exiger que les utilisateurs définissent un mot de passe composé uniquement de chiffres si le même mot de passe peut être nécessaire pour des choses comme l'accès téléphonique automatisé, mais un tel mot de passe ne devrait pas être le principal justificatif d'authentification pour l'accès par ordinateur.
supercat

3

La réponse est l' histoire

Nous semblons oublier que la base de beaucoup de choses vient d'une époque où le stockage n'était pas effectivement libre (sur disque ou en mémoire) lorsque notre capacité à gérer toutes ces choses était légèrement inférieure à ce qu'elle est maintenant et également la capacité des systèmes automatisés tenter de le casser était également un peu moins.

Il y a beaucoup de délires sur les mots de passe basés sur ce que nous savons maintenant et ce que nous pouvons faire maintenant, mais le simple fait est que nous avons souvent affaire à une combinaison de la pensée héritée et des systèmes hérités.

Devrait-il y avoir des restrictions dans les nouveaux systèmes maintenant ? J'espère que non - encore moins de raison maintenant


Voulez-vous dire qu'il y avait des restrictions technologiques avec des espaces dans les mots de passe qui n'existaient pas auparavant? Quel rôle le stockage a-t-il joué exactement dans cela?
Ian Hunter

1
Je suggère que les limites technologiques et les contraintes externes moins complexes (et éventuellement l'utilisation de «trim») signifiaient que les gens pensaient différemment à ce qui serait approprié et permis. Vous pouvez limiter les mots de passe pour vous assurer qu'ils sont susceptibles d'être mémorisés car leur réinitialisation est plus difficile. Il est possible que vous ne les chiffriez pas, car il est relativement difficile (à l'époque) d'accéder à un endroit où vous pouvez les lire (et en tout cas, les systèmes ne sont pas accessibles depuis le monde extérieur). Des moments différents, des processus de pensée entièrement différents qui ont laissé un héritage
Murph

2

À mon humble avis, il est complètement stupide de tout site / application qui utilise le hachage et / ou le salage modernes pour stocker les mots de passe afin de ne pas autoriser les espaces dans les mots de passe. Mais, certains systèmes hérités (lisez-le quelque part) transmettent toujours les mots de passe en texte clair - donc ne pas autoriser les espaces là - bas peut avoir du sens. De plus, certaines applications peuvent "supprimer" toutes les entrées de chaîne qu'elles reçoivent. Donc, un mot de passe commençant ou se terminant par un espace ne va pas être bon (bien sûr, c'était trop artificiel, mais vous pouvez imaginer ce qui ne peut pas arriver avec presque tout le monde qui crée son propre site). Il n'y a rien de "mauvais" à autoriser les espaces dans les mots de passe - comme vous le faites remarquer, les bases de données ne interdiront pas les hachages ou les versions en texte brut.

En fait, la plupart de mes amis Windows ne savent pas qu'ils peuvent utiliser des espaces dans leurs mots de passe. les idées fausses et / ou ignorent les avantages que les espaces peuvent offrir.


1
Je préfère supprimer les espaces de début / fin des mots de passe car ils ont tendance à causer des problèmes, mais ce n'est pas une raison pour les interdire - ils seront simplement supprimés à la fois lors de la configuration et des tests, pas de problème.
Loren Pechtel

Et quels sont exactement les "problèmes"? J'ai souligné dans la réponse que les espaces DEVRAIENT ÊTRE autorisés. "Ils seront dépouillés à la fois sur le réglage et les tests" - Quel est le point alors? puis "1 4m 1337" et "1 4am 1337" hachent tous les deux à la même valeur (en fait, il y a un nombre infini de possibilités en théorie).
yati sagade

What's the point then?Le point mineur est que le mot de passe est moins entropique comme prévu par l'utilisateur. Et certains systèmes suppriment les variables GET / POST par défaut, une modification (peu probable) de ce comportement entraînera des problèmes plus graves.
yannis

@Yati sagade: Je ne parle PAS de supprimer les espaces internes. Je parle d'espaces de début et de fin - les gens ne se rendent pas compte que l'espace est là et cela provoque des échecs de connexion. De même, si vous voyez un mot de passe tout en majuscules, le retourner en minuscules, c'est probablement quelqu'un qui n'a pas réalisé que le verrouillage des majuscules était activé.
Loren Pechtel

-1

C'est fait pour la même raison que de nombreux sites n'autorisent pas les traits d'union, les apostrophes ou les lettres non ASCII dans les noms, même si ce sont des pratiques très courantes même aux États-Unis et qu'il faut plus de travail pour interdire ces caractères que pour simplement autoriser leur.

Cela est également fait pour la même raison que les filtres de mots de nombreux sites ne vous permettent pas d'utiliser des mots comme "arrogant", "retardateur" ou même "accumuler" (bien que de nombreuses insultes raciales courantes soient parfaitement correctes).

C'est parce que beaucoup de développeurs manquent apparemment complètement de bon sens, ou du moins ont une imagination très limitée lorsqu'ils envisagent des entrées et des scénarios utilisateur possibles. Un petit pourcentage d'entre eux peut travailler à partir de fausses informations (que l'exclusion des caractères non alphanumériques est en quelque sorte une pratique standard, ou que l'algorithme de hachage ou la méthode de stockage ne peut pas gérer les espaces ou les caractères spéciaux). D'autres peuvent simplement être paresseux - ils sont préoccupés par les problèmes de jeu de caractères, ils limitent donc simplement les entrées à un espace de caractères minimal. Et puis il peut y avoir ceux qui exercent une validation / assainissement des intrants trop zélés en raison de la paranoïa due à un manque de compréhension des menaces réelles.


Quelle raison auriez-vous à utiliser une liste blanche au-delà de l'application d'un codage de caractères particulier? Le fait que restreindre les caractères arbitraires ne confère aucun avantage tout en affaiblissant les mots de passe choisis par les utilisateurs est ce sur quoi je base cette opinion. Tous les exemples que j'ai donnés sont des symptômes de développeurs qui ne réfléchissent pas suffisamment aux choix de conception.
Lèse majesté
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.