Est-il une bonne idée d'utiliser des caractères unicode non latins dans un mot de passe?
J'ai entendu de nombreuses suggestions sur ce qui fait un bon mot de passe (difficile à deviner, pas un mot de dictionnaire ni de leur permutation, au moins une certaine longueur, etc.) afin qu'il ne puisse pas être fissuré dans une quantité de temps réaliste. Cependant, à partir de ce que je comprends, les techniques et les logiciels de fissuration du mot de passe essaieront d'utiliser des caractères latins, des chiffres et des caractères spéciaux que vous trouverez généralement sur un clavier américain. Par conséquent, serait-il une bonne idée d'inclure des caractères non latins dans un mot de passe?
Par exemple, "PASSW 密码 RD".
Probablement pas - vous trouverez de nombreux problèmes de compatibilité en fonction des ensembles de caractères pris en charge des périphériques que vous devrez peut-être entrer votre mot de passe.
Il existe deux façons de vous assurer que vous avez un mot de passe fort:
- Utilisez une source d'entropie que l'attaquant n'est pas au courant.
- Utilisez assez d'entropie afin que la force brute soit infaisable.
L'approche que votre méthode proposée prend est la première. Il y a généralement moins d'inconvénients de cette dernière approche. Si vous utilisez un mot de passe avec au moins 128 bits d'entropie, il ne peut pas être deviné dans une durée raisonnable. C'est en moyenne - si l'attaquant est très chanceux, ils pourraient deviner la première fois - mais la même chose est vraie avec tous les mots de passe.
Donc, pour obtenir 128 bits d'entropie, vous avez besoin d'un mot de passe avec au moins 20 caractères entièrement aléatoires (en utilisant les deux lettres de boîtier, les numéros plus ASCII symboles) ou vous avez besoin de 10 sélectionnées au hasard DICWORS .
Donc, à mon avis, c'est déjà un problème résolu. Utilisez un générateur de mots de passe sécurisé pour créer un mot de passe aléatoire de 20 caractères si vous n'avez pas besoin de vous en souvenir, ou d'utiliser DICWare si vous le faites.
Généralement, oui. Certains systèmes peuvent ne pas prendre en charge ou permettre des caractères non latins. Dans le backend, la base de données et d'autres systèmes doivent être configurés correctement pour gérer des caractères non latins ou des choses inattendues peuvent se produire. Par exemple, un caractère Unicode multi-bye peut être interprété comme plusieurs caractères d'octets simples (ou quelle que soit la taille attendue du codage utilisé).
Si le système accepte votre entrée et partout où vous entrerez sur le mot de passe vous permet d'utiliser des langues, vous devez être bien. Le seul attrape qui vient immédiatement à l'esprit est s'il y a un nombre maximum de caractères autorisés et que vous utilisez des caractères multi-octets, vous devez terminer la limite ou si elle effectue un type de troncature. Il peut également y avoir un certain type de filtres de sécurité construits en supposant que seuls les caractères latins sont autorisés et que votre entrée pourrait être signalée ou assainie. Toutes ces conditions dépendront du système spécifique et de ce qu'il supporte.
Vous devrez peut-être tester et voir s'il existe des problèmes de compatibilité; Cependant, des points bonus pour vous si cela prend vos caractères simples et le considère que 2 ou plus - vous donnez un mot de passe plus long sans que vous n'ayez pas besoin de vous rappeler plus de pièces. Si le système accepte votre entrée et que cela fonctionne bien. Si vous rencontrez déjà des problèmes étranges, vous espérez-vous être en mesure de réinitialiser et d'utiliser un jeu de latins uni.
Pour référence, faites juste un texte de base à la conversion binaire:
passw密码rd = 01110000 01100001 01110011 01110011 01110111 11100101 10101111 10000110 11100111 10100000 10000001 01110010 01100100
(9 "characters", 13 bytes)
password = 01110000 01100001 01110011 01110011 01110111 01101111 01110010 01100100
(8 "characters", 8 bytes)
D'une manière c'est ce que l'ordinateur voit vraiment. Donc, si le système n'est pas unicode conscient, cela peut devenir fou, ou peut interpréter passw密码rd comme passwå¯ç rd, passw密码rd, etc. Si la fonctionnalité n'est pas implémentée de manière cohérente dans tout le système, la fonction qui enregistre et que le mot de passe peut le voir une manière et les fonctions qui comparent tardivement le hachage peut le faire d'une autre manière.
Oui, ce serait une bonne idée d'utiliser ces personnages.
passw密码rd ne serait probablement pas le meilleur exemple car il s'agit simplement de deux personnages loin du mot de passe, mais il serait certainement plus sûr que password11, p4ssw0rd, ou des permutations similaires.
Étant donné que ces lettres ne sont pas aussi pratiques sur des claviers moyens, la plupart des utilisateurs n'utiliseront probablement pas ces caractères car cela nécessite des efforts supplémentaires pendant le processus de connexion. Les pirates informatiques connaissent ceci et seront très probablement PAS essayer ces personnages aussi souvent. Cela ne signifie pas que l'utilisation de ces caractères est une clé qui vous protégera de brute-forçage, mais ce serait une protection significativement meilleure. Le nombre de caractères possibles augmente considérablement lors de l'utilisation de tels caractères Unicode, augmentant ainsi le temps d'une attaque potentielle de force brute. Pour cette raison, les pirates hallogers décideront probablement de cibler le "fruit de suspension bas", étant des personnes qui utilisent un ensemble de caractères plus petit qui permet moins de possibilités.
Je pense que ce serait une très mauvaise idée. Comme vous n'avez pas besoin de comprendre comment un site Web assainissant votre mot de passe, vous pouvez facilement vous retrouver avec une situation dans laquelle vous mettez un mot de passe unicode long avec beaucoup d'entropie, qui, après l'assainissement, finit par être stocké comme (A Hash of) Seulement le ASCII caractères imprimables Ce mot de passe contenus (ou le code d'assainissement normalisé de votre Unicode) ou même comme (hachage de) une chaîne vide si elle ne contient aucune.
Donc, vous serez tapotez-vous sur le dos, pensant que vous avez une très bonne sécurité, lorsque vous êtes en réalité, votre mot de passe se termine par rapport à (un hachage de) très peu ASCII caractères imprimables ou vides susmentionnés chaîne. Vous pouvez donc toujours vous connecter avec votre mot de passe Unicode, mais quelqu'un d'autre peut-on brute-force-force quelques-un ASCII caractères ou met suffisamment unicode qui est désinfecté (en cas de stockage stocké (en cas de stockage stocké chaîne de caractères).
De plus, si elles changent jamais leur code d'assainissement, vous pouvez être verrouillé de votre compte.
Les caractères unicode bien non ASCII peuvent causer Représentation Problèmes si vous devez les saisir d'une machine non contrôlée, par exemple dans un centre d'affaires de l'hôtel. D'abord, il n'a pas pu avoir le codage attendu. Par exemple é est U + 00E9 ou une petite lettre latine E avec aiguë. Il est normalement codé comme "\xc3\xa9" Avec 2 octets dans UTF-8, mais est l'octet unique "\xe9" en caractères latin-1.
De plus, il a 2 formes normalisées différentes (1). U + 00E9 Si le formulaire de normalisation C (ou la composition canonique) et le formulaire de normalisation D (ou décomposition canonique) U + 00E5 U + 0301: latine petite lettre e avec une combinaison d'accent aigu. Par définition, ces deux formes correspondent au même glyphe, mais presque toute application, quelle que soit la langue dira qu'ils sont des chaînes différentes. Et lorsque vous tapez des caractères non ASCII à partir d'un clavier, vous pouvez difficilement deviner quelle forme sera utilisée.
Longue histoire courte: lors de l'ajout de caractères non ASCII, vous rendez l'entropie croissance qui est bonne, mais à un risque de ne pas être capable de taper le mot de passe d'un système Broighigh. Et une plus grande longueur est généralement un gain d'entropie plus élevé qui ajoute des caractères non ASCII ...