Dois-je supporter l'Unicode dans les mots de passe ?

Question

Je voudrais permettre à mes utilisateurs d'utiliser l'Unicode pour leurs mots de passe.

Cependant, je constate que de nombreux sites ne prennent pas en charge cette fonction (par exemple, Gmail, Hotmail).

Je me demande donc s'il n'y a pas un problème technique ou de convivialité que je néglige.

Je pense qu'il doit s'agir d'un problème de convivialité, car par défaut, .NET accepte Unicode et si Hotmail - ou le nouveau Live mail - est construit sur cette base, je ne vois pas pourquoi ils le restreindraient.

Quelqu'un a-t-il rencontré des problèmes similaires ?

Answer 1

Je suis sûr qu'il n'y a pas de problème technique mais peut-être que gmail et hotmail ne supportent pas cela volontairement. Ce genre de sites web a un large public et devrait être accessible de partout.

Imaginons que l'utilisateur ait un mot de passe en japonais mais qu'il soit en voyage et se rende dans un cybercafé et qu'il n'y ait pas de support en japonais, l'utilisateur ne pourra pas se connecter.

Un autre problème est d'analyser la complexité du mot de passe. Il n'est pas si difficile de s'assurer que l'utilisateur n'a pas tapé un mot courant en anglais, mais qu'en est-il en chinois/russe/thaï. Il est beaucoup plus difficile d'analyser la complexité d'un mot de passe à mesure que l'on ajoute des langues.

Si vous souhaitez que votre système soit accessible, il est préférable de faire en sorte que l'utilisateur soit en mesure de taper son mot de passe sur tous les types de dispositifs/OS/environnements, donc le mot de passe alphanumérique avec les symboles les plus courants( !<>"#$%& etc ) est une sorte de bon ensemble de caractères disponibles partout.

Answer 2

En général, je suis fortement en faveur de ne pas restreindre les types de caractères autorisés dans les mots de passe. Cependant, rappelez-vous que vous devez comparer quelque chose à quelque chose de stocké qui peut être le mot de passe ou un hash. Dans le premier cas, vous devez vous assurer que la comparaison est faite correctement, ce qui est beaucoup plus complexe avec l'Unicode qu'avec l'ASCII seul ; dans le second cas, vous devez vous assurer que le hachage est exactement le même à chaque fois qu'il est saisi. Les formulaires de normalisation peuvent aider ici ou être une malédiction, selon la personne qui les applique.

Par exemple, dans une application sur laquelle je travaille, j'utilise un hachage sur une conversion UTF-8 du mot de passe qui a été normalisé au préalable pour éliminer les problèmes potentiels de combinaison de caractères et autres.

Le plus gros problème de l'utilisateur mai Le problème est qu'ils ne peuvent pas le saisir à certains endroits, comme sur une autre disposition de clavier. C'est déjà le cas pour l'un de mes mots de passe, mais cela n'a jamais posé de problème jusqu'à présent. Et après tout, c'est une décision que l'utilisateur doit prendre en choisissant son mot de passe et non une décision que l'application devrait prendre à sa place. Je doute qu'il y ait des utilisateurs qui utilisent volontiers un Unicode arbitraire dans leurs mots de passe sans penser aux problèmes qui peuvent survenir lorsqu'ils utilisent une autre disposition de clavier. (Cela peut être un problème pour les services basés sur le web plus qu'autre chose, cependant).

Il existe cependant des cas où Unicode est interdit à juste titre. C'est le cas de TrueCrypt, qui impose l'utilisation de la disposition du clavier américain pour les mots de passe au démarrage (pour le cryptage intégral). Il n'y a pas d'autre disposition possible et, par conséquent, l'Unicode ou toute autre disposition de clavier ne fait que créer des problèmes.

Cependant, cela n'explique pas pourquoi ils interdisent l'Unicode dans les mots de passe normaux. Un avertissement serait bienvenu, mais l'interdire purement et simplement est une erreur à mes yeux.

Answer 3

Je me demande donc s'il n'y a pas un problème technique ou de convivialité que je néglige.

Il y a un problème technique avec les mots de passe non-ASCII (et les noms d'utilisateur, d'ailleurs) avec l'authentification de base HTTP. Pour autant que je sache, les sites que vous avez mentionnés n'utilisent généralement pas l'authentification de base, mais il se peut qu'il s'agisse d'un vestige de systèmes qui l'utilisent.

La norme d'authentification HTTP Basic définit un code de base64. username:password symbolique. Cela signifie que si vous avez un deux-points dans le nom d'utilisateur ou le mot de passe, les résultats sont ambigus. De plus, le décodage en base64 du jeton ne donne que des octets, sans indication de la façon de convertir ces octets en caractères. Et devinez quoi ? Les différents navigateurs utilisent des encodages différents pour le faire.

• Opera et Chrome utilisent UTF-8.

• IE utilise la page de code par défaut du système client (qui n'est bien sûr jamais UTF-8) et traite les caractères qui ne s'y trouvent pas à l'aide de l'algorithme standard de Windows consistant à essayer de trouver un caractère qui lui ressemble un peu, ou peut-être pas (peu importe).

• Safari utilise la norme ISO-8859-1 et refuse silencieusement d'envoyer tout jeton d'authentification lorsque le nom d'utilisateur ou le mot de passe contient des caractères qui ne correspondent pas.

• Mozilla prend les 8 bits les plus bas du point de code (similaire à ISO-8859-1, mais plus cassé). Voir bug 41489 pour une discussion tortueuse sans résultat ni progrès.

Si vous autorisez les noms d'utilisateur ou les mots de passe non ASCII, le processus d'authentification de base sera au mieux compliqué et incohérent, et les utilisateurs se demanderont pourquoi il fonctionne ou échoue de manière aléatoire lorsqu'ils utilisent différents ordinateurs ou navigateurs.

Answer 4

Non. Limitez les mots de passe aux caractères ASCII.

Lorsque vous saisissez un mot de passe, des puces s'affichent pour dissimuler le mot de passe.

Mais lorsque vous saisissez le japonais et d'autres langues, vous devez passer par une méthode de saisie, qui convertit les frappes en caractères souhaités. Pour cela, vous devez voir quels sont ces caractères.

Answer 5

Bonne idée.

Rend le mot de passe plus fort, donne plus de liberté aux utilisateurs. Et c'est déjà fait par Windows (depuis au moins Win 2000), Active Directory et LDAP, Novell (depuis au moins 2004).

Certains clients le veulent ( http://mailman.mit.edu/pipermail/kerberos/2008-July/013923.html ) et il existe même une norme sur la façon de le faire correctement ( https://www.rfc-editor.org/rfc/rfc8265 [3] obsolète https://www.rfc-editor.org/rfc/rfc4013 (merci John).