Les utilisateurs devraient-ils être autorisés à utiliser le caractère spécial de leur choix lors de la création d'un mot de passe?
Je suis tombé sur un certain nombre de paramètres de configuration de connexion où il y a liste des caractères spéciaux autorisés et je me demandais:
Cette limitation répond-elle à un besoin de sécurité ou d'utilisation spécifique?
Exemple: une liste de caractères spéciaux pris en charge par Oracle Identity Manager et Microsoft Active Directory pour le champ de mot de passe:
Mise à jour:
Merci à tous pour la réponse généreuse!
Chaque fois que j'ai posé une question qui concerne la sécurité et la convivialité, il semble y avoir un fossé clair entre les partisans de chaque côté. Mais ce n'est pas forcément le cas car c'est un domaine qui nécessite beaucoup de compromis et de compromis… UX en dépend!
Si l'utilisateur peut le saisir, il doit être autorisé dans son mot de passe.
Dire à quelqu'un ce qu'il peut et ne peut pas utiliser dans son mot de passe est toujours mauvais pour l'utilisateur. Les mots de passe sont actuellement le moyen d'authentification le plus universel. Empêcher les utilisateurs d'entrer quoi que ce soit , c'est essentiellement leur dire qui ils peuvent ou ne peuvent pas être.
1. Tout caractère imprimable qu'un utilisateur saisit doit être autorisé.
Les caractères suivants vont bien ...
'A', 'a', 'á', 'Æ', 'æ', 'Ñ', 'ñ', '-', '_', ' ' (space), '\t' (tab), '\n' (newline), ...
Tout simplement parce que je ne sais pas comment soumettre un TAB ou ENTER Le fait de faire partie de mon mot de passe ne me donne pas le droit d'empêcher les autres de le faire.
(Ne vous inquiétez pas, peu de gens essaieront de soumettre un ENTER dans le cadre de leur mot de passe, mais en permettant à quelques-uns de ceux qui le méritent de gagner leur respect.
2. Les touches qui n'affichent pas de caractère imprimable ne doivent pas être autorisées.
Les raisons doivent être évidentes mais pour être complet, je mentionnerai les clés suivantes qui peuvent être détectées mais sont réservées à d'autres actions. Par exemple, une entrée de mot de passe ne doit pas enregistrer que le changement a été effectué plusieurs fois ...
[ctrl], [alt], [shift], [arrow keys], [Apple key], [windows key], etc.
3. Ne pas autoriser certains personnages incite les utilisateurs à remettre en question votre sécurité.
Lorsque vous empêchez les utilisateurs de mettre certains caractères dans leur mot de passe, cela dérange non seulement les gens, mais oblige nombre d'entre eux à se demander ce que vous faites d'autre qui n'est pas sécurisé.
Vous pourriez aussi bien dire ...
"Hé, nous ne voulons pas corriger notre application pour gérer correctement les caractères spéciaux, alors pourriez-vous nous aider en rendant votre mot de passe moins sécurisé?"
Les règles ci-dessous permettront une entrée sécurisée tout en empêchant un utilisateur de se retrouver coincé:
N'affiche pas les caractères que l'utilisateur tape dans les champs de mot de passe (il y a quelques exceptions sur mobile)
Avoir l'utilisateur tapant deux fois son mot de passe est généralement suffisant pour lui faire savoir qu'il a bien compris (c'est-à-dire qu'il n'a pas ajouté accidentellement un espace blanc involontaire, etc.)
Il est important d'avoir un mécanisme de réinitialisation de mot de passe pour gérer tous les cas de verrouillage accidentel.
4. Encourager un utilisateur à en ajouter n'est pas la même chose que d'interdire les caractères.
Une façon d'aider un utilisateur à trouver un mot de passe sécurisé est d'en faire un jeu ...
5. L'avenir de l'authentification
" La technologie qui tuera les mots de passe morts " est un très bon article de gizmodo sur les problèmes auxquels nous sommes tous confrontés avec les mots de passe. Il parle également de nouveaux modèles qui pourraient éventuellement remplacer un jour les mots de passe.
De nombreuses applications mobiles commencent à permettre aux utilisateurs d'afficher ou de masquer les mots de passe en texte brut afin d'augmenter la facilité d'utilisation et de supprimer une barrière à l'entrée. Je voudrais toujours éviter cela parce que le problème qu'il crée est pire que le problème qu'il résout.
Selon ce même article, il apparaît que Touch ID est sur la bonne voie et gagne facilement en ce qui concerne la convivialité. Touch ID a toujours des problèmes majeurs qui le rendent peu pratique. Le plus grand étant qu'il ne fonctionne que sur certains appareils et a des problèmes avec une seule personne contrôlant plusieurs comptes.
La reconnaissance faciale est un autre concurrent car un nombre croissant de caméras à haute densité de pixels pénètrent dans le monde, mais cette approche laisse souvent les gens s'inquiéter de la confidentialité.
Le seul problème partagé par toutes ces nouvelles tentatives d'authentification est le suivant: Vous êtes le mot de passe.
Il est en fait beaucoup plus facile de simuler qui vous êtes que ce que vous savez. De plus, une fois compromis, il est presque impossible de changer (vos empreintes digitales par exemple)
Les mots de passe sont le mécanisme d'authentification de choix depuis longtemps, alors ...
Veuillez ne pas imposer de limitations de caractères arbitraires à mon mot de passe. Merci!
Si un site exige que les mots de passe ne contiennent que certains codes de caractères, un utilisateur pourra saisir le mot de passe dans presque tous les appareils capables de produire ces caractères. Si le mot de passe contient des codes de caractères qui peuvent être entrés sur certains appareils mais pas sur d'autres, alors un utilisateur qui crée un mot de passe sur un appareil qui pourrait entrer les codes qu'il contient mais qui doit ensuite se connecter avec un appareil qui ne peut pas, serait effectivement verrouillé sur son compte.
Sur presque toutes les plateformes raisonnables, les 94 caractères imprimables ASCII seront clairement distincts. Même si une police utilise de manière gênante des glyphes identiques pour I et l, ou pour 0 et O, les personnes qui entrent de tels caractères n'auront généralement aucun doute sur leur entrée. En revanche, sur certaines plates-formes, un utilisateur peut penser qu'il entre un caractère comme ɸ quand il entre dans un φ; si un tel utilisateur se déplace vers une machine où les caractères sont saisis différemment, il peut ne pas être en mesure d'accéder à son compte à moins ou jusqu'à ce qu'il puisse déterminer quels caractères il aurait pu utiliser pour entrer son mot de passe.
Les choses se compliquent encore si l'on tient compte de choses comme la combinaison de signes diacritiques. Certains personnages comme ë ont deux représentations légitimes: une "lettre minuscule latine E avec tréma" [code 0x000EB] ou une "tréma combinatoire" [code 0x00308] suivie de "lettre minuscule latine E" [0x00065]. Certains appareils peuvent ne pas permettre à l'utilisateur de contrôler le formulaire entré. Idéalement, le mot de passe serait converti en une forme normalisée connue avant le hachage, mais il est loin d'être certain que tout le code qui tente de "normaliser" les chaînes Unicode fonctionnera toujours de la même manière (même s'il est spécifié dans, cela ne signifie pas que cela sera effectivement).
Je voudrais ajouter quelque chose au point de DaveAlger. Comme beaucoup de gens, je crée des algorithmes pour mieux me souvenir des mots de passe. J'ai parlé à de nombreuses personnes (de manière informelle) de mots de passe et j'ai entendu beaucoup d'objections
- pourquoi ne puis-je pas utiliser une partie de mon e-mail ou mon nom d'utilisateur dans mon mot de passe?
- pourquoi y a-t-il une limite de caractères? (affecte mon algorithme)
- pourquoi ne puis-je pas utiliser de caractères spéciaux?
- pourquoi dois-je utiliser des majuscules, des chiffres ou des caractères spéciaux?
Presque tout le monde est frustré quand il est obligé de changer son mot de passe. SI le mot de passe soumis est considéré comme non sécurisé (exemple 1234, 1111 ou qwerty), indiquez à l'utilisateur que le mot de passe est rejeté car il est considéré comme non sécurisé. Mais assurez-vous que le mot de passe n'est pas sûr, même s'il ne répond pas à certaines exigences individuelles.
Le mot de passe blueOrangeMetsWasSheaNowCiti est plus sûr que # $ 78rt même s'il n'utilise pas de chiffres ou de caractères spéciaux.
La limitation n'aide pas la convivialité car elle ne peut que frustrer les utilisateurs et, bien que je ne sois pas un expert en sécurité, je ne vois pas comment la limitation d'un jeu de caractères peut, en aucune façon, aider à sécuriser un système.
Cela peut être logique du point de vue de la convivialité et du support.
Si le caractère n'est pas possible de taper sur un clavier/téléphone sans utiliser de codes alt ou copier-coller.
Gardez à l'esprit que les appareils compatibles Internet les plus actifs ont des écrans tactiles. Votre utilisateur peut créer le compte à partir de son ordinateur portable, puis essayer d'accéder au compte avec son téléphone, qui n'est pas capable de saisir le caractère Æ.
Et tous les caractères d'espaces blancs doivent être nettoyés en tant qu'espaces génériques, découpés d'avant en arrière, et plusieurs caractères d'espaces blancs dos à dos étant ignorés et traités comme un seul espace blanc. Pourquoi? Parce que beaucoup de choses ont des problèmes avec les espaces, en particulier les caractères de début, de fin et de plusieurs espaces consécutifs.
Bien que vous devriez probablement autoriser les espaces (les gens aiment utiliser des phrases maintenant), vous voudrez peut-être informer votre utilisateur de la façon dont vous avez rangé son mot de passe, mais qu'il n'a pas à s'en soucier si c'est ainsi qu'il a l'habitude de le saisir. .
L'autorisation de caractères unicode qui doivent ensuite être redirigés via HTTP est également une autre épreuve de prise en charge potentielle.
Ça dépend.
Si vous avez un contrôle raisonnablement fort sur le mécanisme de saisie du mot de passe (dispositions du clavier, piles de logiciels, etc.), laisser les utilisateurs entrer librement tout ce qu'ils veulent est une bonne idée, car cela maximise l'espace de mot de passe disponible. Quelqu'un qui attaque un site en anglais n'essaiera probablement même pas des choses évidentes comme "كلمة المرور" (que Google Translate m'assure être arabe pour "mot de passe"). Dans un tel cas, l'encodage des mixages n'a pas vraiment d'importance, car tout mixage sera le même sur tous les systèmes, s'annulant.
D'un autre côté, si vous essayez de prendre en charge une gamme de systèmes aussi large que possible, vous devez limiter les mots de passe aux 95 caractères imprimables ASCII, afin de continuer la programmation et de supporter les cauchemars à Soutenir tout signifie gérer homoglyphes (Α, А et A ressemblent à un humain, mais ont des valeurs d'octets différentes), caractères en double (le "micro signe" "µ et le" grec minuscule mu "μ représentent le même caractère, mais sont codés avec des valeurs d'octets différentes), différents formes de composition (ñ et ñ se ressemblent, mais le premier est un" n " suivi d'un tilde de combinaison, tandis que le second est un seul caractère précomposé) et différent ordre des caractères de combinaison (ế peut être exprimé comme "e + accent aigu + accent circonflexe" ou "e + circonflexe accent + accent aigu ", qu'un ordinateur considère comme différent) - et c'est juste dans Unicode. Transformations de codage tronquées peut signifier que quelqu'un tente entrer "Pässword" sur un système ISO 8859-1 est interprété comme "Pδssword" par un système ISO 8859-7.
Un problème que j'ai vu avec les mots de passe non ASCII est que certains systèmes traitent caractères et d'autres traitent points de code spécifiques au codage. Le caractère "א" peut être représenté de différentes manières selon l'encodage, et parfois le même caractère peut être représenté de plusieurs manières ("é" peut également être U00E9 Ou U0065 U0301).
Considérez la transition Python2 -> Python3. La sérialisation de "שלום" dans Python 2, puis la comparaison à la même valeur sérialisée avec Python 3, entraînera FAUX comme Python 3 en raison des changements dans la façon dont les chaînes sont représentées en interne en Python. .
PHP a une mésaventure similaire: il traite des octets, pas des caractères. Ainsi, un utilisateur qui a entré "שלום" sur une page avec l'encodage CP-1252 peut ne pas être en mesure de se connecter sur une page avec l'encodage UTF-8. Combinez cela avec l'hôte des problèmes de codage inhérents à l'utilisation des pilotes mysql_* (Moins dans les pilotes PDO, ce qui facilite les choses) et le problème est aggravé.
Dans PHP, j'ai résolu le problème sur les sites Web non anglais en m'assurant que je me connectais correctement à la base de données via UTF-8 (beaucoup plus facile depuis PHP 5.3.3 mais problématique avant cela, même avec PDO, si bien que je me souviens encore du numéro de version critique), en utilisant des requêtes préparées et un hachage approprié, et que je sers toujours la page en UTF-8. Cependant, je n'ai vu aucune fin aux problèmes que mes collègues moins pédants rencontrent avec la question.
Oui, malheureusement, les restrictions sur les caractères que l'utilisateur peut utiliser dans le mot de passe ont du sens du point de vue UX.
Si vous exploitez un service mondial, vous souhaitez que vos utilisateurs puissent se connecter à partir de tous les endroits du monde. Si c'est le cas, vous devez prendre en compte, que malheureusement, les claviers ne le sont pas standardisés.
Si la disposition des caractères de base est variable. Par exemple, en Allemagne, les dieux savent pourquoi, ils ont échangé "Z" avec "Y" et ils ont fait un méli-mélo complet avec d'autres personnages.
Si, en tant qu'utilisateur, vous parvenez à trouver un bouton donné sur le clavier, il est fort probable que vous ne puissiez pas saisir les caractères "nationaux" de votre choix, car chaque pays a son propre clavier disposition (virtuelle, ou dans des cas extrêmes, comme en Allemagne, même physique) et permettant à tout utilisateur de choisir tout la disposition du clavier n'est pas une option, du moins pas sur les machines Windows.
Veuillez noter que la plupart des utilisateurs ne sont pas conscients de ces problèmes.
Il existe donc des raisons pratiques de limiter le choix des caractères que l'on peut avoir dans le mot de passe à l'ensemble qui peut (probablement) être tapé par n'importe quel utilisateur de n'importe quelle machine.
L'authentification et la sécurité sont essentielles. Une faille de sécurité vous tuera.
Avez-vous une idée de ce qui se passe entre un clavier et un serveur? Vous avez la normalisation, l'encodage, les ambiguïtés en Unicode, la sérialisation, le NAT, l'homme du milieu et d'autres mesures. Il s'agit d'une transaction sécurisée de bout en bout qui est utilisée pour toute la session. Les méchants veulent profiter de tout ça.
Une pratique de sécurité courante consiste à limiter la surface d'attaque et à la protéger comme un soldat.
Les programmeurs ne sont pas paresseux: il s'agit de protéger une fonction très sensible et critique que beaucoup de méchants tentent d'exploiter.
Dire "Je veux utiliser n'importe quel caractère, mais protège-moi", c'est comme dire "accepte n'importe quelle forme d'identité mais assure-moi qu'ils sont bien ceux qu'ils disent être". Je ne peux pas monter dans un avion avec ma carte scolaire pour une raison: ce n'est pas aussi sûr.
L'essentiel est qu'un mot de passe sécurisé fonctionnel peut être créé à partir de 128 caractères. Il n'y a aucune raison de sécurité d'en soutenir davantage. La prise en charge de tous les Unicode est une vulnérabilité de sécurité inutile.
Quelques lignes directrices:
Laissez l'utilisateur entrer n'importe quel caractère dans la plage ASCII de 32 (espace) à 126 (~) - ceux-ci devraient être les mêmes dans n'importe quel code de caractère.
Limiter vos utilisateurs à moins de caractères ne fera que les frustrer et les forcera à choisir moins de sécurité ou plus difficile pour eux de se souvenir des mots de passe.
Les caractères ci-dessous ASCII 32 (et ASCII 127 = Delete) ont une signification spéciale, par exemple ESC, Enter (formulaire de soumission), Tab (champ de saut) et d'autres caractères qui ne sont pas destinés à être dactylographiés et ne doivent donc pas être acceptés.
Les caractères ci-dessus ASCII 127 peut ne pas être saisissable sur certains claviers ou appareils (peut empêcher la connexion via le téléphone ou via d'autres PC à l'étranger) et nécessite un stockage Unicode (moins de problème, cependant, vous devez en être conscient)
Ne limitez pas trop la longueur - par ex. laissez les utilisateurs entrer 10s de caractères, par exemple jusqu'à 50 ou 100.
Plus de détails sur les mots de passe dans ma réponse ici .
Que se passe-t-il si cela prend deux semaines pour obtenir la réinitialisation du mot de passe par l'envoi d'une lettre à mon adresse personnelle et que je ne peux pas accéder à ma banque en vacances en raison de leur caractère dans mon mot de passe que je ne peux pas taper sur mon iPhone.
Vais-je blâmer la banque, envisagerais-je de changer de banque ……
Et si mon dos décide à un stade ultérieur, ils souhaitent utiliser des listes déroulantes pour saisir un mot de passe plutôt qu'un champ de texte….
Que faire si le clavier que j'utilise aujourd'hui produit un caractère différent lorsque j'appuie sur £?
Étant donné le risque de réinitialisation des mots de passe, créons-nous simplement un risque différent en permettant aux utilisateurs d'avoir un mot de passe plus susceptible de nécessiter une réinitialisation?
Cependant, si le mot de passe peut être réinitialisé uniquement par le site Web qui m'envoie un e-mail, il devrait autoriser tout ce qui se trouve dans le mot de passe.
Limiter les caractères autorisés dans les mots de passe à un sous-ensemble sain de caractères imprimables est une bonne idée. Plus de flexibilité n'est pas toujours mieux. C'est pourquoi nous avons des limites de vitesse sur les routes. Souvent, l'utilisabilité consiste à protéger les utilisateurs de leur aptitude naturelle à se tirer une balle dans le pied.
Du point de vue de la sécurité côté serveur, la prise en charge des mots de passe Unicode complets ne pose aucun problème. Même si vous ne voulez pas gérer les caractères fous côté serveur, un peu de codage javascript peut facilement pré-convertir tous les mots de passe en notation hexadécimale avant qu'ils ne soient envoyés et traités par le serveur. Mais, pour les raisons indiquées ci-dessus, il convient de le faire -et- également de limiter à un sous-ensemble sain de caractères imprimables.