Je rage à chaque fois que je saisis un mot de passe fort et que le site m’envoie bouler parce que je n’ai pas de caractère autre qu’alphanumérique.
Essayons quelque chose d’un peu plus smart pour évaluer la robustesse d’un mot de passe
Développeurs, vous savez probablement tout ça, mais continuez à lire parce que la fin vous est adressée
Si j’en crois Hackernoon on peut calculer environ 800 millions de SHA256 par seconde sur un matériel qui coûte 0,82 € par heure sur AWS. Ça fait 3,5 10^12 combinaisons par euro.
Traduit autrement, voici le nombre de combinaisons qu’on peut tester, et le même chiffre écrit en puissance de deux (arrondi à la décimale inférieure) :
| 1 € | 3,5 × 10^12 | 2^41,6 |
| 10 € | 3,5 × 10^13 | 2^44,9 |
| 100 € | 3,5 × 10^14 | 2^48,3 |
| 1 000 € | 3,5 × 10^15 | 2^51,6 |
| 10 000 € | 3,5 × 10^16 | 2^54,9 |
| 100 000 € | 3,5 × 10^17 | 2^58,2 |
Quand on vous parle ailleurs de bits d’entropie, ça correspond à ces puissances de 2. Avec 1 000 € on peut tester toutes les combinaisons de SHA 256 d’une chaîne aléatoire de 51 bits.
Ok, mais ça me dit quoi ? Une lettre c’est 26 combinaisons, environ 4,7 bits. Si vous ajoutez les majuscules vous doublez le nombre de combinaisons et vous ajoutez 1 bit. Si vous ajoutez les chiffres et quelques caractères spéciaux on arrive à à peine plus de 6 bits.
Petit calcul, en utilisant juste les 26 lettres de l’alphabet, on peut tester toutes les combinaisons de 8 caractères pour moins de 1 €. Vu qu’on aura de bonnes chances de tomber dessus avant d’avoir testé toutes les combinaisons, autant dire que même avec 9 caractères, votre mot de passe ne vaut pas plus de 1 €.
Combien faut-il de caractères pour se trouver relativement à l’abri (c’est à dire que la somme investie ne peut pas tester plus de 1% des combinaisons) ? Ça va dépendre de ce que vous y mettez comme types de caractères. J’ai fait les calculs pour vous :
| a-z | a-z A-Z | a-z A-Z 0–9 | a-z A-Z 0–9 +-% | |
| 1 € | 11 | 9 | 9 | 8 |
| 10 € | 11 | 10 | 9 | 9 |
| 100 € | 12 | 10 | 10 | 10 |
| 1 000 € | 13 | 11 | 10 | 10 |
| 10 000 € | 14 | 11 | 11 | 11 |
| 100 000 € | 14 | 12 | 11 | 11 |
Et là magie : 8 caractères, même avec des chiffres, des majuscules et des symboles, ça résiste tout juste à 1 €. Et encore, là c’est en partant du principe que vous choisissez réellement les caractères de façon aléatoire, pas que vous ajoutez juste un symbole à la fin ou que vous transformez un E en 3.
Vous voulez que votre mot de passe résiste à un voisin malveillant prêt à mettre plus de 10 € sur la table ? Prévoyez au moins 10 caractères.
Et là, seconde magie : Si vous mettez 10 caractères on se moque de savoir si vous y avez mis des chiffres ou symboles. La longueur a bien plus d’importance que l’éventail de caractères utilisé.
Maintenant que vous savez ça, tous les sites qui vous imposent au moins une majuscule et un symbole mais qui vous laissent ne mettre que 8 caractères : Poubelle.
Je ne suis pas en train de vous apprendre à faire un mot de passe fort. Vous devriez utiliser un gestionnaire de mots de passe et le générateur automatique qui y est inclus.
Je suis en train d’essayer de rendre honteux tous les développeurs qui acceptent de mettre ces règles à la con sur les sites web dont ils ont la charge : Vous imposez des mots de passe qui sont à la fois imbitables et peu robustes.
Vous voulez faire mieux ?
Regardez dans quelle colonne est l’utilisateur en fonction des caractères qu’il a déjà tapé et donnez-lui un indicateur en fonction de la longueur de son mot de passe.
- Mot de passe refusé s’il est sur « Have I Been Pwned? »
- Moins de 10 € ? mot de passe insuffisant, refusé
- Moins de 100 € ? mot de passe faible, couleur rouge
- Moins de 1 000 € ? mot de passe moyen, couleur orange
- Mot de passe sûr, couleur verte, à partir de 10 000 €
Si vous gérez un site central, par exemple un réseau social public, vous pouvez probablement relever tout ça d’un cran.
Si ça donne accès à des données sensibles, à des possibilités d’achat, à la boite e-mail ou à l’opérateur téléphonique, mieux vaux relever tout ça de deux crans.
Le tout prend probablement moins de 10 lignes en javascript. C’est une honte que vous acceptiez encore d’implémenter des règles à la con « au moins une majuscule, un chiffre et un symbole, voici les symboles autorisés […] ».
Développeurs, vous devriez avoir honte.
Ceux qui me disent qu’il ne faut pas utiliser SHA pour les mots de passe vous avez raison, mais ça ne change rien au fond, ça ne fait qu’ajouter un multiplicateur à mes calculs.
Le fond c’est : La longueur compte bien plus que l’éventail des caractères, et imposer des règles complexes différentes sur chaque site est juste pénible pour un bénéfice peu pertinent rapport à un vrai calcul de complexité
SHA256 ou pas (PBKDF2 avec un salt, ce qui est « standard » dans toute entreprise qui se respecte…), dans cette article on ne définit pas le mode d’attaque…
Si l’attaque est « j’ai récupérer la BDD » alors là SHA256 ou autre, c’est important.
Si l’attaque est frontale sur l’application web, il faudrait plutôt calculer le coût d’entrer toutes les combinaisons (bruteforce) possibles sur le service web en question…
Donc je serais plutôt partisan du : « Administrateurs, si vous voulez mettre une politique de mots de passe (peut importe laquelle), très bien, mais pensez à sécuriser la partie authentification (système double-auth, Yubikey) et prévenir les attaques par bruteforce (Fail2Ban, règles iptables et désactivation temporaire du compte cible) »
On parle évidemment d’attaque à froid à partir d’une base de données qui a fuité. Sinon on ne parlerait pas de centaines de millions de tests à la seconde, ni même de faire des calculs de hash.
SHA ou Argon2 ça fait d’énormes différences, mais ça ne reste qu’un coefficient et ça ne change en rien le fond du message « emmerder l’utilisateur avec des symboles et tout le tralala n’a qu’une influence marginale dans un calcul de complexité ». Voir le tout premier commentaire du billet.
On m’oppose PCI-DSS alors je suis allé vérifier (les certifications sont parfois obligées de mettre des règles fixes simples, donc ça aurait été une contrainte possible pour ceux qui ont besoin de cet agrément).
La v3.2.1 impose 7 caractères (seulement?) dont au moins un alphanumérique et un numérique.
Si on se contente de prendre ça au pied de la lettre, on nous impose effectivement d’ajouter des chiffres mais rien ne parle de forcer des symboles ou même de majuscules/minuscules.
Mais surtout PCI-DSS accepte explicitement la notion de « equivalent strength » basée sur un calcul d’entropie, c’est à dire… exactement ce que je fais dans mes calculs.
Clairement, je te suis sur le conseil (arrêtez avec les contraintes débiles de mot de passe !) mais je ne suis pas d’accord avec l’analyse.
Car le conseil le plus important, c’est : stockez vos mots de passe avec un algorithme type PKBDF2, imposant un facteur travail suffisant pour la vérification. Si, partant d’un hash, il faut 0,2 secondes pour vérifier la correspondance avec un mot de passe proposé, le craquage d’un mot de passe alphanumérique (a-zA-Z0-9) de longueur N nécessite :
2 ^ (N * 6) / (5 * M) secondes
où M est le nombre de cœurs dédiés au calcul. Pour reprendre ton exemple (M = 5000 cœurs) :
– 3 caractères : 10 secondes
– 4 caractères : 10 minutes 42
– 5 caractères : près de 12 heures, soit 9,8 €
– 6 caractères : 31 jours et 19h soit 626 €
– 7 caractères : 5 ans et 8 mois, soit 40 000€.
Ce coût est celui d’un bruteforce tenté **en ayant accès directement au hash**, il est multiplié par 1,5 ou 2 s’il faut ajouter la connexion réseau (et dans ce cas, vous êtes beaucoup plus rapidement victime d’un DoS que d’une fuite de mots de passe …).
Moralité : Stockez vos mots de passe de façon sûre et la contrainte » >= 7 caractères alphanumériques » (et absent des bases de mots de passe fuités) est suffisante pour prévenir tout type d’attaque, y compris la fuite des mots de passe stockés en base de données.
Au passage, utiliser PKBDF2 (ou argon2 ou …) vous autorise à avoir absolument n’importe quelle chaîne utf-8 en entrée sans autres contraintes (voire, mais je ne suis pas sûr, n’importe quelle chaîne binaire …).
Je dois avoir mal rédigé le billet parce que vous êtes plusieurs à me répondre ça malgré le tout premier commentaire où j’explicite très clairement : Peu importe.
L’objet du billet n’est pas de donner un coût. C’est de dire qu’emmerder l’utilisateur avec des règles de construction complexes n’a qu’un impact marginal par rapport à la longueur du mot de passe.
Imposer d’ajouter ou non des symboles autres qu’alphanumériques est au mieux équivalent à ajouter un caractère à la chaîne.
La conclusion elle est vrai que tu utilises SHA directement (c’est mal), PBKDF2 (c’est moyen) ou Argon2 (c’est bien) puisqu’utiliser l’un ou l’autre ne change le coût que d’un coefficient fixe.
Et en pratique quand l’utilisateur va mettre un chiffre ou un symbole, ce sera souvent au début ou à la fin, souvent pour remplacer une lettre (souvent les mêmes). Quant aux symboles, on parle quasiment toujours des mêmes, et l’éventail réellement utilisé est très restreint.
Bref, arrêtez d’utiliser des contraintes énormes et donnez juste un feedback à l’utilisateur sur la robustesse réelle de son mot de passe.
Ce n’est pas un problème de développeur … mais de RSSI qui font les specs sécurités qui vont nous dire on veut cette merde, je suis développeur et ça me fait tout aussi chier …
Je refuse totalement l’argument « ce n’est pas ma faute, on m’a dit de faire ça ». Nous avons tous passés l’âge
Ton article est très intéressant ceci étant dit tu peux toujours te lever de bon matin pour faire changer d’avis à mon patron, ce que le RSSI lui dit il prend ça pour parole d’évangile. Certification iso 9001 à la clé qui dit donc assurance par derrière ils sont à l’abri, le seul risque pour eux quand il y a une faille c’est une perte » temporaire » de clientèle.
J’ai un peu parlé du problème dans un des billets suivants : https://n.survol.fr/n/assumer-ses-choix
quelque chose comme zxcvbn ? (Facile de s’en souvenir, c’est la ligne basse sur les claviers qwerty)
https://lowe.github.io/tryzxcvbn/
Bonjour,
Les calculs que vous faites sont certainement juste mais je pense que le raisonnement de base est faux.
Si on impose l’utilisation de caractères non alphanumérique, ce n’est pas pour rendre les mots de passe plus difficile à cracker en « force brut » mais pour éviter les attaques par dictionnaire. En somme pour empêcher les utilisateurs d’utiliser le prénom du petit dernier ou de leur star préférée comme mot de passe, car même si le mot/nom fait 20 caractères, il sera craqué très facilement.
Je continuerais donc, pour cette raison, à imposer un caractère non alphanumérique… et je n’ai pas honte ;)
Par contre, je vous rejoins sur la longueur des mots de passes : 8 caractères, c’est trop peu pour les applications « sensibles ».
En pratique les gens utilisent des substitutions classiques (genre 3 pour E) ou ajoutent le truc qui manque à la fin. L’utilisateur aura toujours moyen de mettre un « 2 » ou une date, ou un « ! ». Ca n’ajoute pas grand chose à la complexité si on part de l’hypothèse que son mot de passe est mauvais à la base.
Si on veut vraiment combattre les mauvaises habitudes, il faut plus regarder du côté de https://haveibeenpwned.com/