Force du mot de passe : Calculs pour les développeurs

Analyse de la force des mots de passe : calculs et recommandations pour les développeurs

Les mots de passe restent la pierre angulaire de l'authentification grâce à leur simplicité et à la familiarité qu’ils offrent aux utilisateurs. Un nom d'utilisateur identifie un compte, tandis qu'un mot de passe confirme la connaissance d'un secret. Malgré des alternatives comme les clés matérielles, les OTP, les biométriques ou WebAuthn, les mots de passe dominent encore les systèmes de connexion à faible friction.

Par exemple, WebAuthn utilise le chiffrement asymétrique : la clé privée reste sur l'appareil, et le serveur vérifie la signature à l'aide de la clé publique. Les données biométriques sont stockées localement — jamais envoyées sur les serveurs — réduisant ainsi les risques d'exposition.

Sécurité concrète : les mathématiques derrière les attaques par force brute

Tout mot de passe peut être cassé par force brute… mais la sécurité repose sur l'impraticabilité économique. Examinons les temps d'attaque pour différentes configurations.

Un code PIN à 5 chiffres (10^5 = 100 000 combinaisons) se brise en quelques secondes à 10 tentatives/seconde. Avec un botnet de 10 000 appareils (100 000 tentatives/seconde), un mot de passe de 5 caractères issu d’un alphabet de 36 caractères (lettres + chiffres) est craqué en moins de 9 minutes.

En élargissant l’alphabet :

• 62 caractères (majuscules/minuscules + chiffres) : 62^5 ≈ 916 millions → environ 2,5 heures avec un botnet.
• 95 caractères (incluant les symboles spéciaux) : 95^5 ≈ 7,7 milliards → environ 21 heures.

La longueur est le facteur clé. Pour 8 caractères parmi 95 : 95^8 ≈ 6,6×10^15 → plus de 2 000 ans à 100 000 tentatives/seconde. Même sans symboles spéciaux (62^8 ≈ 2,2×10^14) → environ 70 ans.

| Ensemble de caractères | Longueur | Combinaisons | Temps (100k/sec) |

|------------------------|----------|--------------|------------------|

| 36 | 5 | 52 millions | 9 minutes |

| 62 | 5 | 916 millions | 2,5 heures |

| 95 | 5 | 7,7 milliards| 21 heures |

| 62 | 8 | 218 billions | 70 ans |

| 95 | 8 | 6,6 billiards | +2 000 ans |

La limitation de taux est essentielle : limiter les requêtes par IP oblige les attaquants à utiliser des botnets distribués, augmentant drastiquement leurs coûts.

Attaques par dictionnaire et schémas courants

Une attaque par force brute complète est inefficace contre les mots de passe longs. Le vrai danger ? Les attaques par dictionnaire et le credential stuffing.

Exemples de mots de passe faibles :

• Qwertyuio1 — motif de parcours au clavier.
• Abcdefghi0 — lettres séquentielles.
• P@ssW0rD36 — substitution en leetspeak.
• Ghbdtn — disposition QWERTY pour "Hello" (en russe).

Recommandation : utilisez des phrases secrètes composées de 4 à 6 mots aléatoires (dans un dictionnaire de 20 000 mots : 20 000^4 = 1,6×10^17 combinaisons → dizaines de milliers d’années pour les casser). Évitez les guillemets ou expressions prévisibles ; utilisez des séparateurs comme des traits d’union ou des espaces.

Les codes PIN (4 chiffres) ne sont pas sûrs en raison de leur faible entropie — ils sont protégés par des limites d’essais (3 à 10 tentatives) et une protection matérielle du hachage.

Erreurs fréquentes des développeurs dans le stockage des mots de passe

Les mots de passe ne doivent jamais être stockés en clair. Utilisez plutôt des algorithmes de hachage puissants comme bcrypt, Argon2 ou scrypt. Les erreurs courantes :

• Stocker les mots de passe en texte clair ou utiliser des hachages faibles comme MD5/SHA-1.
• Omettre le sel — rendant les attaques par table arc-en-ciel possibles.
• Hachage faible sans itérations suffisantes — permettant une attaque rapide via GPU.
• Absence de limitation de taux ou de protections CAPTCHA.
• Ignorer les vérifications de credential stuffing — ne pas contrôler si les paires login/mot de passe figurent dans des bases de données de fuites (ex. Have I Been Pwned?)

Bonnes pratiques :

• Utiliser Argon2id avec des paramètres mémoire-intensifs.
• Attribuer un sel unique par utilisateur.
• Mettre en place une limitation de taux (ex. 5 tentatives par minute par IP).

Recommandations concrètes

Pour les utilisateurs :

• Utiliser un mot de passe unique pour chaque service.
• Viser ≥12 caractères ou une phrase secrète (4+ mots aléatoires).
• Utiliser un gestionnaire de mots de passe :

* Local uniquement (KeePassXC) : contrôle total, synchronisation manuelle.

* Basé sur le cloud (Bitwarden) : synchronisation automatique, protection par mot de passe principal.

• Activer l’authentification à deux facteurs (TOTP préféré — éviter SMS).

Pour les développeurs :

• Exiger des phrases secrètes ou des mots de passe d’au moins 16 caractères.
• Hacher avec Argon2 (p=2, m=64Mo, t=3).
• Appliquer une limitation de taux avec backoff exponentiel.
• Introduire les Passkeys/WebAuthn dans les nouveaux systèmes.
• Surveiller les fuites avec des outils comme Have I Been Pwned ?

Points clés

• La longueur prime sur la complexité : 95^8 offre bien plus de résistance que 62^12.
• La limitation de taux + les botnets = augmentation exponentielle du coût pour les attaquants.
• Les phrases secrètes aléatoires offrent >10^17 combinaisons possibles.
• Stockez uniquement des hachages salés avec Argon2 ; le texte clair = compromission immédiate.
• Des mots de passe uniques empêchent les attaques par credential stuffing.

— Editorial Team