Quelle longueur maximale de mot de passe choisir lors de l'utilisation de bcrypt?
Lorsque j'ai généré un mot de passe pour GitHub avec KeePass, j'ai reçu un message sur le site GitHub disant que la limite de la longueur du mot de passe est de 72 caractères. Cela semblait bizarre que ce ne soit pas une puissance de 2, j'ai donc googlé un peu et il est apparu que 72 sont les octets max pour l'algorithme brypt. Il semble donc logique de limiter le nombre à 72, car les mots de passe plus longs seraient de toute façon tronqués à 72.
Ensuite, j'ai généré un mot de passe pour Discord et il est apparu que la longueur maximale est de 128 caractères. Mais j'ai pensé que je vérifierais si les 72 premiers caractères de mon mot de passe suffiraient. Et oui, mon mot de passe de 128 caractères est également tronqué à 72 premiers, donc je suppose que Discord utilise également bcrypt.
Donc, la question est, est-il préférable de simplement définir la limite de longueur du mot de passe à 72 caractères ou de laisser les utilisateurs choisir des mots de passe plus longs (combien de temps? 128, 256 octets?) même s'ils seront tronqué?
Le premier critère est sécurité et alors seulement la convivialité, le stockage ou la difficulté de mise en œuvre.
Je ne suis pas favorable à la troncature silencieuse car elle induit les utilisateurs en erreur en leur faisant croire que leur mot de passe entier a été accepté alors qu'il ne l'était pas. Je préférerais qu'un système définisse simplement une longueur maximale, si nécessaire, et restreigne l'utilisateur à cela lors de la saisie du mot de passe. n mauvais scénario dont j'ai entendu parler est un changement de code qui commence à traiter les caractères au-delà de la longueur maximale précédente et soudain, les utilisateurs de mot de passe plus longs ne peuvent pas se connecter. Le système n'a qu'un enregistrement des 72 premiers caractères et leur chaîne plus longue ne correspondent pas à cela sans l'ancienne troncature du système. Cela conduit à des utilisateurs frustrés.
Comme alternative à la troncature à 72 caractères, vous devriez considérer pré-hachage du mot de passe avec quelque chose comme SHA-256. Le permet à la chaîne de mot de passe de l'utilisateur au-delà de 72 caractères d'être prise en compte tout en offrant la protection informatique de bcrypt.
Je suis généralement la personne qui plaide contre des limites idiotes, mais je dois me demander: qui utilise sérieusement des mots de passe de plus de 72 caractères? Un mot de passe aussi long serait très difficile à saisir, il s'agit donc presque certainement d'un robot (ou ctrl + v d'un gestionnaire de mots de passe). Les robots * et les gestionnaires de mots de passe ne se soucient pas s'ils doivent se souvenir de chaînes alphanumériques aléatoires plutôt que de mots de passe.
En supposant qu'ils n'utilisent pas de caractères spéciaux, soit 26 + 26 + 10 = 62 possibilités par caractère et disons jusqu'à 72 caractères. Cela permet des possibilités 62^72 = 1.13*10^129. En convertissant en bits d'entropie, un nombre beaucoup plus gérable, nous obtenons log(62^72)/log(2) = 428.7 bits d'entropie.
La dernière fois que j'ai vérifié, les clés 256 bits sont considérées comme raisonnables même après le quantum, donc cela devrait être beaucoup .
Dans le cas rare où il s'agit d'une phrase secrète, prenons un dictionnaire très standard: celui par défaut sur mon système Debian. Après quelques élagages standard (insensibilité à la casse; suppression des variantes possessives comme "cheval" au lieu de "cheval"), il contient environ 50 000 mots. Je ne suis pas sûr de ce calcul, mais je pense que cela signifie que chaque mot, lorsqu'il est choisi au hasard (comme vous devriez le faire avec des phrases secrètes), donne environ log(50000)/log(2)=15.6 bits d'entropie. La longueur moyenne d'un mot est généralement considérée comme 5 caractères, plus un espace, donc 72 est d'environ 12 mots.
Cela revient à 15.6*12 = 187.3 Bits d'entropie dans une phrase de passe de 72 caractères. En tant que borne inférieure, parce que mon dict ne contient pas tous les mots. Je dirais que tu es bon.
La vraie limite idiote est les 72 caractères de bcrypt, mais si c'est avec cela que vous devez travailler, je pense que c'est une limite raisonnable à fixer pour les utilisateurs.
* OK, très bien, peut-être que les robots s'en soucieraient. Demandez-moi à nouveau lorsque la modification des droits du robot sera disponible.
Edit: Je répondais au titre. Pour répondre à d'autres questions dans votre message:
Donc, la question est, est-il préférable de simplement définir la limite de longueur de mot de passe à 72 caractères ou de laisser les utilisateurs choisir des mots de passe plus longs [...] même s'ils seront tronqués?
Ne tronquez pas silencieusement. Il n'y a aucun avantage à cela. Soit vous obtiendrez des demandes de support "boo-hoo je ne peux pas utiliser un mot de passe à 105 caractères" ou finalement quelqu'un découvre "OMG je n'ai qu'à entrer les premiers 56% de mon mot de passe pour que ça marche, c'est quoi cette merde?! ?!? ". Je pense que ce dernier a en fait un point raisonnable et le premier sera extrêmement rare (si jamais).
Le premier critère est la sécurité et ensuite seulement l'utilisabilité
Je pense que vous pourriez être intéressé à en savoir plus sur les certificats TLS côté client.