Dans les canaux Canary et Dev du navigateur, une fonction permet maintenant de détecter un formulaire d’inscription et de proposer un mot de passe aléatoire.
Dans sa forme actuelle, la fonction cherche à savoir quelle taille maximale peut accepter le formulaire. Le navigateur y va également de ses conseils : un bon mot de passe doit avoir entre 8 et 72 caractères composés de minuscules, majuscules, chiffres et caractères spéciaux, le tout sans jamais composer d’information évidente comme un mot du dictionnaire.
Si l’utilisateur accepte le mot de passe aléatoire généré, Edge l’enregistre alors pour l’ajouter à sa collection. À la connexion suivante, il le fournira automatiquement.
Si Edge a votre préférence et que vous n’utilisez pas déjà un gestionnaire indépendant comme BitWarden, Dashlane ou LastPass, la nouvelle fonction pourrait être très intéressante, surtout depuis qu’Edge est devenu multiplateforme.
Dans le cas contraire, la suggestion peut être désactivée, tout comme le gestionnaire interne de mots de passe.
Commentaires (9)
#1
Pourquoi limiter la longueur du mot de passe à 72 caractères. Un mot de passe à 100 caractères est-il moins fiable qu’un mot de passe à 72 caractères ?
#1.1
C’est pour réduire la tailles des paires compte/MDP a transférer et stoker sur les serveurs de la NSA, qui comme tout le monde le sait, utilise encore des cartes perforées !
#1.2
Mon hypothèse :
Il faut peut-être regarder peut être par rapport au pratique de sauvegarde du mot de passe coté serveur. Il y a des chance qu’il soit enregistré sous la forme d’un hash, donc réduit à un nombre fixe d’octet. En tenant compte du nombre de collision possible, il existe une taille de mot de passe original qui n’augmente plus la sécurité : tout les hash sont statisquement déjà dans des mots de passe plus petit. Du coup, il est possible qu’un mot de passe à 100 caractères n’apporte rien de plus qu’un mot de passe à 72 caractères.
#1.3
72 caractères, ça peut se rapprocher de 64 octets utiles (à la très grosse louche) donc 512 bits, ce qui semble effectivement raisonnable par rapport à ce que tu exposes.
#1.4
J’avais lu qu’un mot de passe est haché et au delà de 50-72 octets, il est tronqué, donc qu’il fasse 72 ou 120 octets, il sera pas plus fort dans un cas que dans l’autre.
Ca dépend des algo de hachage, mais il me semble que le plus utilisé est dans le cas ci-dessus (me rappel plus du nom par contre !)
#2
Mais un bon mot de passe, c’est un mot de passe… difficile à deviner pour un attaquant. Ca varie donc car les pirates s’adaptent. L’avantage du mot de passe “fort” (long et complexe), c’est qu’il sera forcément difficile pour un attaquant (pour de la force brute, encore une fois) : l’entrée a suffisamment d’entropie (= d’imprévisibilité) pour être inaccessible à la force brute.
Note : 72 octets = 8*72 bits d’entropie = 2^576 possibilités.
#2.1
Bon, je ne suis pas un expert du tout dans le domaine :)
Mais du coup j’ai recherché ce à quoi je faisais allusion, il me semblait bien que le passe était tronqué, je faisais référence à Bcrypt, qui visiblement est populaire comme algorithme de hachage :
https://dzone.com/articles/be-aware-that-bcrypt-has-a-maximum-password-length#:~:text=Bcrypt is a popular password,length to 50-72 bytes.
#3
Pour être stocké en clair dans une BDD ouverte aux quatre vents ?
Blague à part, je ne suis pas fan de ce genre de fonctionnalité vendue sous couvert de “simplicité”. L’utilisateur perd de la maîtrise. Que se passe-t-il si le profil associé au navigateur est perdu pour une raison X ou Y ?
A titre personnel, j’estime que dépendre du navigateur pour générer et stocker des secrets est la dernière des choses à faire.
#3.1
Oui mais pour ceux qui ont la fâcheuse habitude du P@$$w0rd (au mieux) en pensant que c’est fort, cela peut être pas mal. Pour les autres, isl ont déjà les bonnes pratiques.