Maintenant, je me demande ce qu'il en est pour quelque chose de bien plus court mais finalement très similaire : ✔️🐎🔋📌
Alors, je te déteste (cordialement, hein), parce que tu mets précisément le doigt sur une situation où scorepw ne va servir à rien...
Comme je le mentionne en fin de journal, scorepw (ou plus exactement, les bibliothèques dont il dépend, notamment Zxcvbn-C) fait plus ou moins n’importe quoi en présence de caractères non-ASCII. C’est valable pour les caractères accentués, c’est a fortiori valable pour des caractères de ce genre.
À mon avis, tous ces résultats surestiment largement le « mot » que tu donnes.
C’est particulièrement vrai pour Zxcvbn-C, qui ne connaissant pas UTF-8 traite en fait ✔️🐎🔋📌 comme un mot de 18 caractères dont les valeurs s’étalent sur toute la plage de 0 à 255 (d’où une estimation d’entropie qui crève le plafond mais à laquelle je ne me fierai pas).
Zxcvbn-CPP s’en sort mieux en considérant correctement 4 caractères Unicode au lieu de 18 octets, mais même comme ça l’entropie estimée me semble trop haute.
En général, quand on estime l’entropie d’un mot de passe, on part du principe que la « structure » du mot de passe (comment il est formé) est connue de l’attaquant. Par exemple, quand Randall estime que correcthorsebatterystaple a environ 44 bits d’entropie, c’est en supposant que l’attaquant sait que le mot de passe est formé de quatre mots courants choisis au hasard.
Une estimation correcte de ✔️🐎🔋📌 qui suit le même principe devrait à mon avis assumer que l’attaquant sait que le mot de passe est formé non pas de quatre caractères Unicode arbitraires (choisis dans la totalité d’Unicode), mais de quatre « symboles » provenant d’une plage restreinte d’Unicode (par exemple la plage des « Mscellaneous SYmbols », de U+1F300 à U+1F5FF).
C’est peut-être d’ailleurs ce que fait l’implémentation CoffeeScript de Zxcvbn, parce qu’elle considère ce mot de passe très moyen (à juste titre selon moi).
[^] # Re: Correct horse battery staple
Posté par gouttegd . En réponse au journal Scorepw, un évaluateur de mots de passe. Évalué à 6.
Alors, je te déteste (cordialement, hein), parce que tu mets précisément le doigt sur une situation où scorepw ne va servir à rien...
Comme je le mentionne en fin de journal, scorepw (ou plus exactement, les bibliothèques dont il dépend, notamment Zxcvbn-C) fait plus ou moins n’importe quoi en présence de caractères non-ASCII. C’est valable pour les caractères accentués, c’est a fortiori valable pour des caractères de ce genre.
À mon avis, tous ces résultats surestiment largement le « mot » que tu donnes.
C’est particulièrement vrai pour Zxcvbn-C, qui ne connaissant pas UTF-8 traite en fait ✔️🐎🔋📌 comme un mot de 18 caractères dont les valeurs s’étalent sur toute la plage de 0 à 255 (d’où une estimation d’entropie qui crève le plafond mais à laquelle je ne me fierai pas).
Zxcvbn-CPP s’en sort mieux en considérant correctement 4 caractères Unicode au lieu de 18 octets, mais même comme ça l’entropie estimée me semble trop haute.
En général, quand on estime l’entropie d’un mot de passe, on part du principe que la « structure » du mot de passe (comment il est formé) est connue de l’attaquant. Par exemple, quand Randall estime que correcthorsebatterystaple a environ 44 bits d’entropie, c’est en supposant que l’attaquant sait que le mot de passe est formé de quatre mots courants choisis au hasard.
Une estimation correcte de ✔️🐎🔋📌 qui suit le même principe devrait à mon avis assumer que l’attaquant sait que le mot de passe est formé non pas de quatre caractères Unicode arbitraires (choisis dans la totalité d’Unicode), mais de quatre « symboles » provenant d’une plage restreinte d’Unicode (par exemple la plage des « Mscellaneous SYmbols », de U+1F300 à U+1F5FF).
C’est peut-être d’ailleurs ce que fait l’implémentation CoffeeScript de Zxcvbn, parce qu’elle considère ce mot de passe très moyen (à juste titre selon moi).