Voici le temps nécessaire à un pirate pour craquer votre mot de passe en 2025

Moi j@ vais enc*re pLus l!on, je chiff453**, tou€$5 mes com55413tions.
C’est vraiFhygj##4F&z7qz6C7qMXt beacyqg!DNj plus fiaoD67oQ3X7h et sûr.
Là par exfhN$F7b9spPsHMQ$YT6j j’EQ8bJ?
Merde, ça décDyY!yP?mL$B&#eLX96s3 !!
Rahh bordllb$GH4NTE8T4J4g7BKhr6 ça m’éneiTEX6m@eh#3C3x
PjdsmTn!7$4M!d9$cMkseB&46hLK#XxkKarP#smcSe7ncLCJAcXNMp54m@636@rz4R$g&pJNmx!XYcK&8QE9Ck7eoA?&PGn?6G4K

Donc en 2024 il faut 50 minutes pour brute force un password en minuscule de 7 lettres et en 2025 il faut 20 heures

Ou bien c’est juste la 5090 qui est moins performante que la 4090

Votre résumé en trois points est biaisé :
« 1. En 2025, les mots de passe de huit caractères ou moins ne sont plus assez sécurisés contre les attaques. »

C’est en parti faux, puisque évidemment ça va dépendre du type de caractères qu’on met dans le mdp.
La bonne pratique étant toujours de combiner majuscule, minuscule, caractère spéciaux, chiffres (peu importe l’ordre).

ça reste qu’une information partielle, qui ne représente pas forcément la majorité des cas puisque c’est aussi lié à l’encodage des mots de passe (bcrypt est en parti dépassé, on préférera des algos comme sodium), et la façon dont sont codés les softs.

c’est surtout le temps qu’il faut pour décoder un hash bcrypt avec 12 rtx 4090 (c’est marqué).

cela implique :

• qu’avec plus de puissance c’est plus rapide
• qu’il faut déjà avoir obtenue le hash en amont…

en conclusion je ne suis pas certains qu’utiliser soduim soit plus « strong » car il suffit de générer un hash avec l’un ou l’autre des algo et de comparer avec celui que l’on a obtenu en amont…

Je pense que la subtilité est le (10) précisé derrière bcrypt sur le tableau de 2025 par rapport à celui de 2024.

bcrypt est un algorithme itératif dont on peut décider du nombre d’itérations, ce qui permet d’augmenter sa complexité avec le temps pour suivre l’évolution du matériel.

Je suppose que leur (10) signifie qu’ils ont demandé un coût de 10, et peut-être qu’en 2024 le coût utilisé étant moindre. Sachant que chaque augmentation du coût de 1 unité multiplie le temps de traitements par 2.

Vu que le temps de traitement est ici 24 fois plus long, alors que les 5090 sont censées être plus rapides que les 4090, mais pas deux fois plus rapides, on peut supposer que le coût utilisé en 2024 était 5 au lieu de 10. Ce qui est un peu con, parce que ça fait pas mal d’années qu’il est recommandé d’utiliser au moins 10, et certaines implémentations utilisent même déjà une valeur par défaut plus élevée (par exemple dans la dernière versions de PHP, c’est 12 par défaut).

EDIT : c’était bien 5 en 2024, comme on peut le voir sur le blog de Hive Systems :


(avec une erreur quand même, le coût de 10, c’est 1024 itérations, pas 32 768)

Si ce n’est qu’une question de temps, de toute façon bcrypt permet d’augmenter le coût.

Par contre si je me trompe pas sodium permet aussi de moduler le coût en mémoire, pas seulement le coût en puissance de calcul, ce qui offre une possibilité supplémentaire d’augmenter sa robustesse sans pour autant augmenter le coût CPU, ce qui permet de garder des systèmes très réactifs (peu de temps CPU passé à hasher/vérifier le mot de passe) tout en restant bien résistant au brute force par GPU (le besoin mémoire empêchant d’exploiter à fond le parallélisme, si par exemple tu as besoin de 100 Mo de RAM pour calculer un hash, une RTX 5090 ne pourra plus qu’en calculer 320 en parallèle, au lieu de quasiment 22 000).

Tu as sûrement raison.
Lors de la publication des délais 2024 par HiveSystems (le tableau dans l’article) il y a eu beaucoup de critiques sur les chiffres indiqués (= « pas réalistes »).
Je suppose qu’ils ont « renforcé » leur méthode (et prennent désormais le soin de préciser le nombre d’itérations).
Après la fiabilité de ces indications reste relative (y compris pour 2025, cf l’algo de hash, la CG utilisée)… mais ça reste quand même une des rare publication qui permet d’avoir une idée du délai nécessaire (saluons tout de même le travail).

Comme je l’ai dit dès le départ - tu sembles avoir lu uniquement la fin - le simple fait de suivre les bonnes pratiques change tout, dès lors qu’un algorithme de cryptage récent est mis en œuvre derrière.

je pense plus que c’est toi qui ne fais pas l’effort de lire et de comprendre ce que les gens te répondes car je ne parle pas du tout des bonnes pratique, juste le fait qu’utiliser sodium ou bcrypt ne change grand chose…

et je remet encore une couche en disant que si, 8 caractère, même avec de bonnes pratiques, c’est à réserver à des mots de passe non sensible…

Tu as mal lu justement :
à aucun moment j’ai dit qu’utiliser sodium à la place de bcrypt changeait la face du monde.
J’ai dit que sodium était souvent préféré dans les applis récentes car considéré comme plus robuste (avec un sel).
J’ai dit que le choix de l’algorithme pour l’encodage avait son importance (certains sont encore en SHA256).

Evidemment que huit caractères c’est trop court, malgré ça entre sept et huit caractères on voit déjà l’impact conséquent d’appliquer les bonnes pratiques.