Chrome les mots de passe générés ne sont pas à haute entropie?
Sur Chrome, si vous ouvrez une page d'inscription, elle vous proposera de remplir et de mémoriser le champ du mot de passe. Je l'ai fait et j'ai obtenu la séquence de mots de passe suivante comme générée:
suCipAytAyswed0
LUnhefcerAnAcg2
it2drosharkEweo
UndosnAiHigcir0
AKDySwaybficMi5
DorrIfewfAidty5
MeecradGosdovl9
KasEsacHuhyflo4
OngouHemNikEyd0
Dans tous ces cas, il n'y a que n chiffre, et dans tous sauf le troisième, le chiffre est à la fin. La chance que j'en obtienne autant avec ce modèle exact est extrêmement faible, et je l'ai vu dans d'autres mots de passe générés par Chrome, donc je suis convaincu que cela continuerait si j'en générais plus.
Cela semble juste étrange, ne serait-il pas plus facile de générer le mot de passe comme une collection aléatoire de lettres et de chiffres que d'imposer un modèle étrange; étant donné que ceux-ci ne sont pas censés être mémorisés? Pourquoi Chrome ferait-il autre chose?
Réponse de Conor est un bon point de départ, mais si vous creusez dans la source de Chromium, la situation commence à paraître un peu plus sombre (mais toujours mieux que de ne pas utiliser de gestionnaire de mot de passe).
Chrome 68 (version actuelle au 1er août 2018)
Jusqu'à la version 68 Chrome suit FIPS 181 pour générer un mot de passe prononçable à 15 caractères autorisant les majuscules, les minuscules et les chiffres. Si le résultat ne contient pas à la fois une lettre majuscule et un chiffre, il change la première lettre minuscule en majuscule et change le dernier caractère minuscule en un chiffre aléatoire.
Malheureusement, l'entropie d'un mot de passe FIPS 181 est assez difficile à calculer, car il génère des syllabes de longueur variable plutôt que des caractères, et il existe un tas de règles dictant si une syllabe est autorisée ou non.
La non-uniformité a de graves conséquences. Un 1994 papier (page 192) estimait que pour pénétrer dans 1 compte sur 100 avec des mots de passe de 8 caractères, un attaquant n'aurait qu'à essayer 1,6 million de mots de passe. Même si l'augmentation de la longueur de 8 à 15 double l'entropie, c'est encore probablement moins de 60 bits d'entropie en moyenne1, bien que cela soit légèrement amélioré en raison de la capitalisation.
standard d'origine ne semble pas prendre en charge les lettres ou les chiffres majuscules, et l'implémentation2 ne met en majuscule que la première lettre d'une syllabe avec une chance de 50% (de façon intéressante y est remplacé par w dans le tablea de caractères vérifiés, donc y ne sera jamais capitalisé). Cela signifie qu'au lieu d'ajouter environ 1 bit d'entropie par lettre, la capitalisation n'ajoute que 1 bit par syllabe. Le nombre de syllabes n'est pas constant, il est donc difficile de déterminer combien d'entropie cela ajoute réellement, mais étant donné la rareté des syllabes à une lettre, il ajoute presque certainement moins de 8 bits en moyenne.
Les chiffres et les symboles sont pris en charge en transformant chaque syllabe d'une lettre en un chiffre ou un symbole avec 50% de chances (bien que la fonction de symbole ne soit pas utilisée). Malheureusement, comme vous l'avez remarqué, les syllabes à une seule lettre sont rares3, donc ForceFixPassword finit généralement par remplacer la dernière lettre minuscule par un chiffre.
Il peut y avoir plus de problèmes, mais je suis un peu fatigué de le regarder. En bref, ce n'est pas une très bonne méthode pour générer des mots de passe, et l'entropie est nettement inférieure à ce que l'on pourrait attendre pour la longueur. En pratique, cela est probablement correct pour l'utilisateur moyen, car cela signifie qu'il n'utilisera pas son mot de passe à faible entropie préféré dans 20 endroits différents, mais il est certainement possible de le casser pour un attaquant déterminé et financé avec un hachage rapide (c'est-à-dire pas a bon hachage de mot de passe ) du mot de passe.
Chrome 69 (sortie prévue en septembre)
Les choses se présentent beaucoup mieux dans Chrome 69. Le jeu de caractères est composé de lettres majuscules et minuscules, de chiffres et des symboles -_.:! avec ce qui suit supprimé pour plus de lisibilité :
l(lettre minuscule L)I(lettre majuscule i)1(chiffre un)O(lettre majuscule o)0(chiffre zéro)o(lettre minuscule O)
La génération fonctionne en en ajoutant un caractère aléatoire de chaque classe jusqu'à ce que le nombre minimum pour ladite classe soit atteint. Par défaut et tel qu'il est actuellement utilisé, il s'agit d'un caractère minuscule, d'un caractère majuscule et d'un chiffre.
Ensuite, le reste du mot de passe est rempli avec des caractères aléatoires uniformément choisis parmi toutes les classes de caractères (en respectant un nombre maximum pour chaque classe, actuellement inutilisé).
Enfin, comme des caractères ont été ajoutés au début du mot de passe à partir de classes prévisibles afin de satisfaire aux exigences, la chaîne est mélangée au hasard . Le brassage se produit jusqu'à 5 fois si deux tirets ou traits de soulignement sont adjacents afin d'améliorer la lisibilité, de sorte que cela réduira très légèrement l'entropie, mais la réduction est si légère qu'elle est imperceptible (et la suppression du tiret ou du soulignement des symboles autorisés serait être pire).
Avec 61 caractères possibles, un mot de passe entièrement aléatoire aurait un journal2(6115) = 88,96 bits d'entropie. En utilisant l'inclusion-exclusion pour tenir compte des caractères requis, je trouve 88,77 bits d'entropie:
61^15 all possible passwords
-53^15 passwords without digits 2-9 (0 and 1 are excluded)
-37^15 passwords without lowercase letters (l and o excluded)
-37^15 passwords without uppercase letters (I and O excluded)
+29^15 add back passwords excluded twice for lack of digit and lowercase
+29^15 add back passwords excluded twice for lack of digit and uppercase
+13^15 add back passwords excluded twice for lack of lowercase and uppercase
-5^15 remove all-symbol passwords that were excluded then added back
Le mélange supplémentaire réduira également une fraction de bit, mais je n'ai pas le temps de le calculer pour le moment. Au final, le mot de passe devrait avoir plus de 88 bits d'entropie, ce qui est plutôt bien.
L'ancien générateur existe toujours dans la version 69, mais quand j'ai testé la version de développement, il utilisait le nouveau. Je ne sais pas s'il existe un moyen d'utiliser l'ancien générateur.
1. L'entropie moyenne n'est pas nécessairement utile avec des distributions non uniformes, le document original de 1975 donne un exemple (pages 29-30) d'un générateur qui produit un mot de passe unique (par exemple "mot de passe") avec une chance de 50%, et un mot de passe d'entropie élevé sinon. L'entropie moyenne peut être élevée, mais il y a toujours 50% de chances que le mot de passe soit deviné immédiatement. Même ainsi, en extrapolant à partir de analyse de 1994 , je pense qu'il devrait toujours avoir bien plus de 40 bits dans le pire des cas.
2. L'implémentation n'est pas réellement celle de Chrome, mais provient du programme APG , avec des modifications mineures pour la compatibilité
3. Test avec apg révèle que les syllabes à une seule lettre se produisent réellement dans environ 33% des mots de passe, mais 70 à 75% d'entre elles n'ont qu'une syllabe à une seule lettre à la fin.
Permettez-moi de commencer par une mise en garde importante et précise:
http://dilbert.com/strip/2001-10-25
Les maths
En regardant les probabilités réelles, il y a 62 caractères possibles (a-zA-Z0-9) et donc en supposant que tous sont également répartis, cela signifie que tout caractère donné a environ 16% de chances d'être un chiffre.
Vous nous avez montré 136 caractères au total, ce qui signifie qu'en moyenne, il devrait y avoir ~ 21 chiffres au lieu des 9 que vous avez indiqués. En parcourant 1000 essais aléatoires, j'obtiens une moyenne de 21,5 chiffres dans une telle analyse avec un écart-type de 4,3. Cela signifie que votre chaîne de 136 caractères avec seulement 9 chiffres est une valeur aberrante de 3 sigma (seulement un changement de 0,3% en raison du hasard). Bien sûr, cela suppose que vous n'aviez aucun exemple avec plus de chiffres que vous avez omis de votre exemple.
La conclusion
Cela suggère que le manque de chiffres n'est pas seulement aléatoire. Cela pourrait signifier quelques choses: soit l'algorithme de génération de mot de passe que google utilise ne colle qu'un chiffre à la fin, soit il y a un problème avec son algorithme de génération de mot de passe ou sa source d'entropie. Sans regarder leur source, il est difficile de dire lequel de ces cas est le plus probable. Bien sûr, ce n'est pas aussi simple que de simplement coller un chiffre à la fin, car vous avez un exemple avec un chiffre vers le début. Donc, si c'est un résultat intentionnel de leur algorithme de génération de mot de passe, alors leur algorithme est très étrange, ce qui me fait penser que quelque chose d'autre se passe.
Mise à jour Selon la réponse d'Androl ci-dessus, l'algorithme de génération de mot de passe de chrome fait en effet quelque chose de très étrange.
La réponse
Bien sûr, rien de tout cela ne répond à votre question: ces mots de passe ont-ils suffisamment d'entropie? Ignorant le chiffre de caractère aléatoire inconnu, nous pouvons penser à cela au moins comme une chaîne de lettres aléatoires de longueur 14. Une telle chaîne (en supposant qu'ils utilisent un bon CSPRNG) aurait 1,06e24 valeurs possibles, soit ~ 80 bits d'entropie. À titre de comparaison, une chaîne de 15 caractères composée de lettres ou de chiffres aurait environ 90 bits d'entropie. Est-ce une entropie "suffisante"? Eh bien, c'est une question beaucoup plus difficile à répondre. Cela dépend - ce mot de passe est-il ensuite stocké sur un site Web qui utilise md5 et fuit sa base de données pour les plates-formes de craquage hors ligne? Est-il stocké sur un site Web qui stocke les mots de passe en texte brut (auquel cas aucune quantité d'entropie n'a d'importance)? Que diriez-vous d'un site Web qui sécurise votre mot de passe avec les meilleures pratiques modernes? Cette réponse donne une comparaison utile et suggère que pour sha256 ordinaire, un mot de passe avec 80 bits d'entropie est effectivement non craquable (avec beaucoup de mises en garde):
https://security.stackexchange.com/a/168511/149676
En conséquence, je dirais que même s'ils ne randomisent pas correctement les chiffres, le mot de passe est suffisamment long pour qu'il y ait plus qu'assez d'entropie dans un avenir prévisible.
Vous avez deux hypothèses erronées dans votre question qui conduisent à la réponse pourquoi Chrome génère des mots de passe comme celui-ci et non, par exemple, p ^ & 7 + 4 + {ZgfnP # P /.
Tout d'abord, vous supposez que les mots de passe ne sont pas censés être mémorisés et doivent donc être complètement aléatoires. Ils ne sont pas. Chrome, comme de nombreux générateurs de mots de passe aléatoires, crée des mots de passe prononçables, comme indiqué en détail dans la réponse d'AndrolGenhald.
L'utilisation de mots de passe prononçables au lieu de charabia réduit les erreurs de saisie, permet au mot de passe d'être transmis à une autre personne au téléphone, par exemple, et facilite leur mémorisation. Pourquoi supposez-vous que les mots de passe Chrome ne sont pas censés être mémorisés? Très peu de gens de nos jours visitent Internet avec un seul appareil.
Deuxièmement, vous supposez que les mots de passe doivent être compliqués. Il s'agit d'une idée fausse courante qui a été falsifiée à plusieurs reprises, la plus officielle étant le retrait des recommandations de complexité du NIST SP-800 (voir, par exemple https://www.passwordping.com/surprising-new- password-guidelines-nist / ).
Les mots de passe doivent, avant tout, être longs . Chrome remplit bien cette condition (12 caractères est un minimum recommandé actuel pour les applications Web non critiques).
À la lumière de ces faits, les mots de passe générés par Chrome satisfont aux normes de mot de passe modernes, modernes . Des améliorations peuvent être discutées et sont certainement possibles, mais ils sont certainement sur la bonne voie.
Notez que ce n'est qu'une supposition de ma part, mais il est possible que cela soit une tentative de rendre les mots de passe plus faciles à mémoriser et/ou à transcrire dans une zone de saisie de mot de passe. En plus du placement des nombres impairs, je remarque que les exemples fournis semblent être principalement prononçables, et j'ai vu d'autres générateurs de mots de passe faire quelque chose de similaire (par exemple LastPass a une option pour créer un mot de passe généré "Facile à dire " ). Il existe des algorithmes publics pour ce faire (par exemple https://exyr.org/2011/random-pronounceable-passwords/ ).
Les rendre prononçables et avoir un placement de nombres apparemment non aléatoire diminue évidemment l'entropie, mais sans connaître l'algorithme réellement utilisé, il est impossible de dire de combien. Il est possible que les développeurs de Chrome Chrome aient évalué l'entropie générée et décidé que les avantages liés à la convivialité l'emportent sur l'entropie perdue et que l'entropie restante est encore relativement sécurisée.