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_Ở!d
contient 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%A9
envoi? 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.