Déve­lop­peurs, vous devriez avoir honte — Règles de mots de passe

Je rage à chaque fois que je saisis un mot de passe fort et que le site m’en­voie bouler parce que je n’ai pas de carac­tère autre qu’al­pha­nu­mé­rique.

Essayons quelque chose d’un peu plus smart pour évaluer la robus­tesse d’un mot de passe

Déve­lop­peurs, vous savez proba­ble­ment tout ça, mais conti­nuez à lire parce que la fin vous est adres­sée

Si j’en crois Hacker­noon on peut calcu­ler envi­ron 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 combi­nai­sons par euro.

Traduit autre­ment, voici le nombre de combi­nai­sons qu’on peut tester, et le même chiffre écrit en puis­sance de deux (arrondi à la déci­male infé­rieure) :

1 €3,5 × 10^122^41,6
10 €3,5 × 10^132^44,9
100 €3,5 × 10^142^48,3
1 000 €3,5 × 10^152^51,6
10 000 €3,5 × 10^162^54,9
100 000 €3,5 × 10^172^58,2

Quand on vous parle ailleurs de bits d’en­tro­pie, ça corres­pond à ces puis­sances de 2. Avec 1 000 € on peut tester toutes les combi­nai­sons de SHA 256 d’une chaîne aléa­toire de 51 bits.

Ok, mais ça me dit quoi ? Une lettre c’est 26 combi­nai­sons, envi­ron 4,7 bits. Si vous ajou­tez les majus­cules vous doublez le nombre de combi­nai­sons et vous ajou­tez 1 bit. Si vous ajou­tez les chiffres et quelques carac­tères spéciaux on arrive à à peine plus de 6 bits.

Petit calcul, en utili­sant juste les 26 lettres de l’al­pha­bet, on peut tester toutes les combi­nai­sons de 8 carac­tères pour moins de 1 €. Vu qu’on aura de bonnes chances de tomber dessus avant d’avoir testé toutes les combi­nai­sons, autant dire que même avec 9 carac­tères, votre mot de passe ne vaut pas plus de 1 €.

Combien faut-il de carac­tères pour se trou­ver rela­ti­ve­ment à l’abri (c’est à dire que la somme inves­tie ne peut pas tester plus de 1% des combi­nai­sons) ? Ça va dépendre de ce que vous y mettez comme types de carac­tères. J’ai fait les calculs pour vous :

a-za-z
A-Z
a-z
A-Z
0–9
a-z
A-Z
0–9
+-%
1 €11998
10 €111099
100 €12101010
1 000 €13111010
10 000 €14111111
100 000 €14121111

Et là magie : 8 carac­tères, même avec des chiffres, des majus­cules et des symboles, ça résiste tout juste à 1 €. Et encore, là c’est en partant du prin­cipe que vous choi­sis­sez réel­le­ment les carac­tères de façon aléa­toire, pas que vous ajou­tez juste un symbole à la fin ou que vous trans­for­mez 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 carac­tères.

Et là, seconde magie : Si vous mettez 10 carac­tères on se moque de savoir si vous y avez mis des chiffres ou symboles. La longueur a bien plus d’im­por­tance que l’éven­tail de carac­tères utilisé.


Main­te­nant que vous savez ça, tous les sites qui vous imposent au moins une majus­cule et un symbole mais qui vous laissent ne mettre que 8 carac­tères : Poubelle.

Je ne suis pas en train de vous apprendre à faire un mot de passe fort. Vous devriez utili­ser un gestion­naire de mots de passe et le géné­ra­teur auto­ma­tique qui y est inclus.

Je suis en train d’es­sayer de rendre honteux tous les déve­lop­peurs qui acceptent de mettre ces règles à la con sur les sites web dont ils ont la charge : Vous impo­sez des mots de passe qui sont à la fois imbi­tables et peu robustes.


Vous voulez faire mieux ?

Regar­dez dans quelle colonne est l’uti­li­sa­teur en fonc­tion des carac­tères qu’il a déjà tapé et donnez-lui un indi­ca­teur en fonc­tion 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 insuf­fi­sant, 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 proba­ble­ment rele­ver tout ça d’un cran.

Si ça donne accès à des données sensibles, à des possi­bi­li­tés d’achat, à la boite e-mail ou à l’opé­ra­teur télé­pho­nique, mieux vaux rele­ver tout ça de deux crans.

Le tout prend proba­ble­ment moins de 10 lignes en javas­cript. C’est une honte que vous accep­tiez encore d’im­plé­men­ter des règles à la con « au moins une majus­cule, un chiffre et un symbole, voici les symboles auto­ri­sés […] ».

Déve­lop­peurs, vous devriez avoir honte.

Rejoindre la conversation

11 commentaires

  1. 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é

  2. 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) »

    1. 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.

  3. 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.

  4. 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 …).

    1. 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.

  5. 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 …

    1. 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

      1. 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.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

À propos de ce site, du contenu, de l'auteur
Je poste parfois ici des humeurs ou des pensées. Parfois je change, parfois je me trompe, parfois j'apprends, et souvent le contexte lui-même évolue avec le temps. Les contenus ne sont représentatifs que de l'instant où ils ont été écrits. J'efface peu les contenus de ce site, merci de prendre du recul quand les textes sont anciens. Merci

À toutes fins utiles, ce site est hébergé par Scaleway, ONLINE SAS, joignable par téléphone au +33 (0)1 84 13 00 00 et joignable par courrier à l'adresse BP 438 - 75366 Paris Cedex 08.