Cela ressemble beaucoup à Fencepost Security. Imaginez que vous dirigez une installation entourée de clôtures en mailles de chaîne et d'une hauteur de 500 pieds. Dans quelle mesure la sécurité serait-elle améliorée en faisant de cette clôture une hauteur de 3 000 pieds? Aucun - parce que quiconque essaie d'entrer ne va pas monter les 500 pieds; ils vont creuser en dessous, percer un trou, etc.

De même, vous avez un mot de passe qui contient, disons, 20 caractères alphanumériques aléatoires. C'est 62 ^ 20 possibilités. Vous envisagez de le changer en 20 caractères Unicode aléatoires. Ce qui augmente considérablement l'espace de possibilité, sauf que forcer brutalement un mot de passe aléatoire de 20 caractères n'est pas la façon dont les choses vont être compromises.

C'est une bonne idée du point de vue de la sécurité. Un mot de passe contenant des caractères Unicode serait plus difficile à forcer qu'un mot de passe contenant des caractères ASCII de même longueur. Cela tient même si vous comparez la longueur en octets au lieu de la longueur des caractères, car Unicode utilise le bit le plus significatif, contrairement à ASCII.

Cependant, je pense que ce ne serait pas pratique car les bogues Unicode sont si courants . Je pense que si vous utilisez des mots de passe Unicode partout, vous rencontrerez plus de deux sites sur lesquels vous auriez des problèmes de connexion, car les développeurs n'ont pas correctement implémenté le support Unicode pour les mots de passe.

Ignorant l'argument Security by Obscurity, c'est une question fondamentale d'entropie. Un mot de passe Unicode à 8 caractères est plus sûr qu'un mot de passe ASCII à 8 caractères, mais moins sûr qu'un mot de passe ASCII à 64 caractères.

En général, je suis d'accord avec Sjoerd - ceux-ci sont susceptibles de causer plus d'inconvénients que d'avantages. En plus de cela, si jamais vous avez besoin de saisir manuellement un mot de passe aléatoire, Unicode va probablement vous rendre la vie misérable.

Cependant, pour le cas extrême où vous devez utiliser un service qui prend activement en charge l'unicode tout en appliquant un limite de longueur maximale du mot de passe (encore une fois, ignorer cela indique généralement d'autres échecs de sécurité) il y a un argument pour cela.

La seule raison valable à laquelle je peux penser pour utiliser des caractères Unicode dans les mots de passe est si le nombre de caractères (et non d'octets) dans un mot de passe pour un site particulier est limité (comme cette banque stupide qui avait auparavant un maximum de 10 caractères), de sorte qu'il soit facilement deviné dans un jour ou deux. Dans ce cas, vous pouvez utiliser Unicode (si les propriétaires du site vous le permettent) pour obtenir plus d'entropie dans votre mot de passe pendant que vous demandez aux propriétaires du site de se conformer au NIST 800-63-3 et supprimer les restrictions de longueur (et hacher correctement pour que le stockage des mots de passe ne soit pas un problème).

Je voulais également corriger une idée fausse ici:

Unicode utilise le bit le plus significatif alors que l'ASCII

Bien que vrai pour l'ASCII normal, l'ASCII étendu que certains gestionnaires de mots de passe (par exemple KeePass) peuvent utiliser dans la génération de mots de passe utilise chaque bit de chaque octet, ayant ainsi un entropique plus élevé densité que même Unicode, qui a encore une structure pour indiquer combien d'octets suivants font partie du même caractère (notez qu'il existe une chose telle qu'une séquence d'octets invalide en Unicode).

Étant donné qu'un site qui vous limite aux mots de passe courts ne hache probablement même pas correctement leurs mots de passe (ce qui entraîne l'échec des mots de passe Unicode ou leur stockage avec th e mauvais encodage), vous ne devriez presque jamais perdre de temps à vous soucier des mots de passe Unicode, car même si vous êtes tellement distrait par vos personnages amusants (et le fait que vous devez réinitialiser votre mot de passe car il a été stocké étrangement), un attaquant pourrait deviner vos questions (in) -security ou en utilisant la cryptographie chocolatée pour accéder à votre compte.

Cette approche pourrait réduire votre sécurité globale dans certains cas, pas l’améliorer.

La sécurité des informations se compose de trois attributs: confidentialité, intégrité et disponibilité (le Triade CIA). En vous concentrant exclusivement sur l'un, vous pouvez facilement oublier l'importance des autres.

La confidentialité des mots de passe est assurée par les principes de l'entropie: à quel point votre mot de passe est-il «impossible à deviner»? Ceci est généralement mesuré par la taille de l'espace de devinettes de force brute, exprimée en termes de puissances de 2 ou bits. Un attaquant par force brute n'a que tant de capacité à deviner; en sélectionnant un mot de passe plus long pour augmenter cette entropie, vous pouvez dépasser toute capacité connue ou prévue à deviner. Obtenir l'entropie sur 80 bits (ou choisir votre valeur) mettra le mot de passe hors de portée même des acteurs des États-nations. Indépendamment de la description trop simplifiée ci-dessus, le fait est qu'aller au-delà de tout ce qui est «hors de portée» n'ajoute pas de manière significative à votre sécurité. Et ce n'est pas pertinent pour la sécurité si vous obtenez l'entropie souhaitée en utilisant 10 caractères Unicode ou 17 caractères ASCII.

La disponibilité signifie "puis-je accéder à mes données quand j'en ai besoin?" Si vous utilisez des jeux de caractères Unicode complets, vous risquez de vous heurter à divers sites qui ne prennent pas en charge Unicode, ou des navigateurs ou des systèmes d'exploitation qui implémentent Unicode de manière incorrecte, ou des sites qui traduisent de manière invisible Unicode en ASCII sous les couvertures. La confusion qui en résulte augmente le risque de restreindre votre futur accès aux données. Cela représente une diminution potentielle de la disponibilité future.

En général, la probabilité qu'un attaquant force votre mot de passe 80 bits est loin d'être aussi élevée que la probabilité de rencontrer un site mal codé qui ne gère pas l'Unicode correctement. Par conséquent, votre sécurité globale pourrait être diminuée au lieu d'être augmentée.

Bien sûr, de nombreux sites ont la longueur des mots de passe et d'autres restrictions qui limitent considérablement l'entropie de vos mots de passe. Dans ces cas, l'utilisation de l'ensemble Unicode complet peut augmenter l'entropie de vos mots de passe, en supposant qu'ils ne présentent pas d'autres défauts cachés. Ainsi, sur ces sites, vous améliorez peut-être votre sécurité; mais il est pratiquement impossible de dire de l'extérieur si un site gère correctement vos données de mot de passe.

Ce n'est peut-être pas une réponse directe, mais si le mot de passe n'est conservé que numériquement, alors vous devriez vous demander pourquoi vous générez un mot de passe , au lieu d'un tableau d'octets. Une fois que vous considérez le tout comme de simples octets, la question ne s'applique plus.

De plus, longueur> complexité dans tout ce qui concerne les mots de passe.

Il existe une RFC sur votre problème: Préparation, application et comparaison de chaînes internationalisées représentant les noms d'utilisateur et les mots de passe dont le résumé est:

Ce document décrit les méthodes mises à jour pour gérer les chaînes Unicode représentant les noms d'utilisateur et les mots de passe. L'approche précédente était connue sous le nom de SASLprep (RFC 4013) et était basée sur Stringprep (RFC 3454). Les méthodes spécifiées dans ce document fournissent une approche plus durable de la gestion des noms d'utilisateur et des mots de passe internationalisés.

Si vous lisez le français, vous pouvez également en trouver une bonne explication ici: http : //www.bortzmeyer.org/8265.html.

La section 8 de la RFC traite spécifiquement de la sécurité des mots de passe utilisant "n'importe quel" caractère Unicode, avec les sections suivantes:

• 8.1. Force du mot de passe / de la phrase secrète
• 8.2. Comparaison mot de passe / phrase secrète
• 8.3. Comparaison d'identifiants
• 8.4. Réutilisation de PRECIS
• 8.5. Réutilisation d'Unicode

Ajoutant aux autres bonnes réponses, je veux juste souligner ce qui peut mal tourner le long du tuyau en utilisant l'ensemble complet Unicode pour les mots de passe.

En supposant que vous utilisez un chaîne UTF-8 plus ou moins valide,

• il y a des caractères interprétés comme un saut de ligne au milieu du plan multilingue de base comme U + 2029 Séparateur de paragraphe. Vous pourriez ne pas être en mesure de les saisir dans un champ <input> simple.
• il y a les deux caractères d'espacement qui peuvent ou non être supprimés par une langue trim () méthode
• si vous utilisez des caractères de substitution (U + D800-U + DFFF), non-caractères comme U + FDD0, caractères à usage privé ou caractères non attribués (bien que des séquences UTF-8 valides), le comportement d'un ensemble d'outils donné est fondamentalement indéfini (supprimer, remplacer, rejeter, ne rien faire ou toute combinaison de ceux-ci)
• si vous ajoutez des signes diacritiques, tout outil en cours peut changer cela en représentation NFC ou NKD, en modifiant les octets du mot de passe.
• et c'est juste du haut de ma tête. Je suis sûr que j'ai oublié beaucoup d'autres problèmes possibles, si les mots de passe sont choisis parmi toute la gamme Unicode.

Donc, comme ce que @JohnDeters a suggéré, cela pourrait être une mauvaise idée car l'avantage d'un espace source plus grand est surpondéré par les parties mobiles du traitement de texte en cours de route.

Ce qui compte pour la sécurité, c'est l'entropie du mot de passe - combien de bits d'informations réelles y a-t-il dans le mot de passe.

L'autre aspect du problème est la difficulté de se souvenir du mot de passe et de le saisir. Imaginez que vous essayez de taper votre mot de passe sur un iPhone et que vous vous rendez compte que vous ne pouvez pas (je n'ai pas vérifié à quel point il est difficile de taper des caractères Unicode arbitraires). Ou vous vous rendez compte qu'il est très, très difficile de le saisir correctement à 100%. Ou cela vous prend juste du temps - j'ai peut-être un mot de passe avec la même entropie et plus de caractères, mais deux fois plus rapide à taper. Et vous avez besoin de quatre tentatives pour bien faire les choses, tandis que la mienne a raison la première fois.

D'autres ont amplement souligné le risque que les services pour lesquels vous utilisez ces mots de passe n'implémentent pas correctement Unicode. J'ajouterai que les services que aujourd'hui font pourraient demain cesser de le faire, mais sinon je vais sauter ce sujet.

Un élément que je penser qu'il faut considérer ici est de se demander: combien de temps faut-il à un mot de passe pour atteindre un certain niveau de sécurité? Supposons que nous voulons que nos mots de passe soient aussi forts qu'une clé cryptographique de 128 bits (ce qui est probablement excessif pour la plupart des mots de passe de sites Web; je recommande 80 bits). Si vous vous en tenez à des mots de passe ASCII aléatoires, alors un mot de passe de 19 caractères tiré des ~ 95 caractères ASCII imprimables atteint ce niveau. (Le calcul: un ensemble d'environ 100 éléments équivaut à environ 6,6 bits / élément (puisque log2 (10) ≈ 3,3 et log2 (100) est le double), et 128 ÷ 6,6 ≈ 19,4. Donc, 19 caractères ASCII sont en fait environ 126 bits, pas 128, mais meh.)

Unicode a actuellement environ 130 000 points de code définis, un nombre que nous approcherons simplement de 2 ^ 17. Cela signifie que pour atteindre le niveau 128 bits, vous avez besoin de 7 points de code Unicode (128 ÷ 17 ≈ 7,5, donc 7 points de code ne représentent que 119 bits environ, mais, encore une fois, meh.)

Pour une sécurité de 80 bits niveau, ce qui, à mon avis, est plus judicieux pour la plupart des sites Web, est de 12 caractères ASCII contre 5 points de code Unicode.

Êtes-vous prêt à prendre un énorme coup de facilité d'utilisation et à risquer des bogues de site Web juste pour que vous puissiez avoir 5 ou Mots de passe à 7 caractères au lieu de 12 ou 19 caractères? Je ne pense pas que ça en vaille la peine.

Eh bien, Unicode est «juste» une liste de quelque chose de plus de 130000 caractères. UTF-8 est le codage le plus courant qui prend ce grand nombre et le «convertit» en un nombre de base 256 (ou plus précisément, les règles ont plus de sens en octets binaires) selon un ensemble de règles. Ainsi, si vous souhaitez utiliser un encodage utf-8, vous serez lié à de nombreuses règles réduisant efficacement le caractère aléatoire que vous pourriez souhaiter. Et je ne sais pas comment vous pourriez utiliser toute l'interprétation Unicode.

Si vous n'êtes pas préoccupé par les caractères imprimables, vous pouvez considérer l'ensemble de l'ASCII (ou plus préférablement une extension 8 bits), mais à ce point, pourquoi même s'embêter avec la norme d'interprétation des caractères? Ne pourriez-vous pas simplement utiliser une simple structure binaire aléatoire sans forme alors?

Même si vous utilisez uniquement le stockage numérique, je détesterais être l'utilisateur qui a besoin de taper quelque chose et qui n'a pas reconnu la différence entre （et (. (Indice: ils sont doubles et simples) spaced)

En utilisant cet exemple sensible à la largeur, comme indiqué dans d'autres réponses, vous vous attendez à ce que la prise en charge de celles-ci fonctionne - selon le classement SQL défini ici, un mot de passe incorrect serait correct!

Non. Vous voulez augmenter la base d'une fonction exponentielle tout en risquant de casser beaucoup de choses (c'est à dire des appareils qui ne peuvent pas taper vos caractères spéciaux, etc.). Calculez l'entropie de votre mot de passe unicode et rallongez votre mot de passe ascii jusqu'à ce qu'il ait plus d'entropie.

az vaut à lui seul 26 ^ (longueur). disons que vous obtenez 256 ^ (longueur) et éventuellement 2 octets par caractère avec unicode. Ensuite, vous pouvez trouver le seuil de rentabilité 26 ^ (ascii_length) > 256 ^ (2 * unicodelength) quelque part. Choisissez cette longueur comme ascii_length et vous pouvez toujours écrire votre mot de passe et avoir la même sécurité.

Si le site ne prend pas en charge les mots de passe longs (honte à eux), je soupçonnerais ils ne peuvent pas non plus garantir un bon support Unicode. Peut-être que vous serez verrouillé la prochaine fois qu'ils mettront à niveau une bibliothèque interne. Alors pourquoi risquer un problème là-bas? Et un problème difficile à expliquer au support utilisateur, qui sait à peine ce que signifie unicode.

Ce n'est pas une bonne idée de générer des mots de passe Unicode aléatoires, car le mot de passe généré peut être illisible pour l'utilisateur. Mais le texte de la question parle de l'utilisation de mots de passe Unicode, et c'est une bonne idée et recommandée par la section NIST 800-63-3 5.1.1.2 Vérificateurs de secrets mémorisés qui dit:

Les vérificateurs DOIVENT exiger que les secrets mémorisés choisis par l'abonné comportent au moins 8 caractères. Les vérificateurs DEVRAIENT autoriser les secrets mémorisés choisis par l'abonné d'au moins 64 caractères. Tous les caractères ASCII [RFC 20] d'impression ainsi que le caractère espace DEVRAIENT être acceptables dans les secrets mémorisés. Les caractères Unicode [ISO / ISC 10646] DEVRAIENT également être acceptés.

Aux fins des exigences de longueur ci-dessus, chaque point de code Unicode DOIT être compté comme un seul caractère.

Il continue:

Si les caractères Unicode sont acceptés dans les secrets mémorisés, le vérificateur DEVRAIT appliquer le processus de normalisation pour les chaînes stabilisées en utilisant la normalisation NFKC ou NFKD définie dans la section 12.1 de l'annexe 15 de la norme Unicode .

Pour résumer: l'utilisation d'Unicode augmente l'entropie et facilite la vie des utilisateurs qui ne maîtrisent pas l'anglais.