L'attaque par dictionnaire — Fonctionnement exhaustif

Document de référence pour le projet Time2Crack

Destinataires : développeurs, chercheurs en sécurité, utilisateurs avancés

Table des matières

1. Vue d'ensemble

L'attaque par dictionnaire est la méthode de cracking de mots de passe la plus ancienne, la plus simple conceptuellement, et statistiquement la plus efficace sur la majorité des mots de passe humains réels. Son principe : tester, dans l'ordre de probabilité décroissante, une liste de candidats précompilée — le "dictionnaire" — plutôt que d'énumérer exhaustivement toutes les combinaisons possibles comme le fait la force brute.

Dans Time2Crack, l'attaque dictionnaire modélise deux mécanismes distincts mais complémentaires :

Ces deux détections sont indépendantes et complémentaires : HIBP couvre les credentials compromis exacts, la wordlist couvre les mots courants non encore fuités.

2. Contexte historique et académique

2.1 Origines

L'attaque par dictionnaire précède l'ère moderne de la sécurité informatique. Les premiers systèmes Unix stockaient les mots de passe en clair dans /etc/passwd, rendant toute attaque dictionnaire triviale dès que le fichier était accessible.

2.2 Les fuites fondatrices

Certaines fuites ont transformé le paysage de l'attaque par dictionnaire en révélant la distribution réelle des mots de passe humains :

• Le mot de passe #1 ("123456") représentait 290 731 comptes (2%)

2.3 Benchmarks de référence pour l'attaque dictionnaire

Une wordlist de 200 000 entrées testée à la vitesse d'un RTX 4090 :

L'attaque dictionnaire est donc quasi-instantanée pour MD5, SHA-1 et NTLM — et reste très rapide même pour bcrypt sur de petites listes.

3. Fondements conceptuels : pourquoi les dictionnaires fonctionnent

3.1 La loi de puissance des mots de passe humains

Toutes les études empiriques convergent vers la même observation : la distribution des mots de passe humains n'est pas uniforme — elle suit une loi de puissance (Zipf). Quelques mots de passe concentrent une fraction démesurée des choix.

Conséquence directe : les 10 mots de passe les plus courants couvrent ~5% des comptes. Un attaquant qui teste seulement 10 candidats a déjà une chance sur 20 de réussir — statistiquement, c'est énorme pour le volume de bruit généré.

3.2 Biais cognitifs dans la création de mots de passe

Les humains ne choisissent pas au hasard. Ils appliquent systématiquement des heuristiques qui rendent leurs mots de passe prévisibles :

3.3 La notion de "mot de passe déjà dans les listes"

Un mot de passe peut être dans une liste d'attaque pour deux raisons distinctes :

Ces deux cas correspondent à des attaques de nature différente, avec des vitesses différentes — et c'est ce que Time2Crack modélise précisément.

4. Architecture d'une attaque dictionnaire moderne

4.1 Pipeline général

Une attaque dictionnaire moderne se déroule en plusieurs phases :

Phase 1 : Constitution de la wordlist
    ├── Mots de passe fuités (HIBP, RockYou, Collections)
    ├── Wordlists linguistiques (dictionnaires, prénoms, lieux)
    ├── Wordlists thématiques (sport, pop culture, tech, religion)
    └── Wordlists contextuelles (domaine de l'entreprise cible, noms d'employés)
Phase 2 : Preprocessing de la wordlist
    ├── Tri par fréquence (les plus probables d'abord)
    ├── Déduplication (pas deux fois le même candidat)
    ├── Filtrage par longueur (longueur cible + ±2)
    └── Normalisation (lowercase, Unicode NFC)
Phase 3 : Calcul des hashes candidats
    ├── Pour chaque candidat w dans la wordlist :
    │     hashcandidat = hashalgo(w)
    │     if hashcandidat == hashcible : TROUVÉ
    └── Vitesse : 168 GH/s pour MD5 sur RTX 4090
Phase 4 : Analyse des résultats
    └── Rapport des passwords crackés, statistiques de couverture

4.2 Optimisations hardware

Les attaques dictionnaire modernes sont massivement parallélisées sur GPU :

Pour une wordlist de 14 milliards d'entrées (taille HIBP) sur 12× RTX 4090 :

Cette différence de ~9 ordres de grandeur entre MD5 et bcrypt explique pourquoi le choix de l'algorithme de hachage est critique.

4.3 Ordre de test des candidats

La wordlist n'est pas testée dans l'ordre alphabétique — elle est triée par probabilité décroissante :

Ce tri garantit que si le mot de passe est "faible", il sera trouvé dans les premières millisecondes — quelle que soit la vitesse de hachage.

5. Les corpus de mots de passe réels

5.1 Have I Been Pwned (HIBP)

HIBP est la référence mondiale car :

Un attaquant disposant du dump HIBP complet peut tester en priorité les ~14 milliards de candidats dans l'ordre de fréquence décroissante. Pour les algorithmes non salés (MD5, SHA-1), cette liste couvre de l'ordre de 50 à 70 % de tous les mots de passe réels utilisés en ligne.

5.2 RockYou (2009) — corpus fondateur

5.3 Collections de wordlists spécialisées

Ces corpus sont téléchargeables publiquement — leur existence est un fait établi de la sécurité offensive.

6. La vérification k-anonymat HIBP : une attaque en temps réel

6.1 Le protocole k-anonymat

Time2Crack intègre une vérification HIBP en temps réel qui reproduit exactement ce qu'un attaquant ferait avec la base HIBP — mais de façon à ne jamais transmettre le mot de passe en clair ou son hash complet.

Le protocole k-anonymat fonctionne ainsi :

1. Calculer SHA-1(password)      → par exemple "CBFDAC6008F9CAB4083784CBD1874F76618D2A97"
Envoyer seulement les 5 premiers caractères à l'API HIBP : "CBFDA"
L'API retourne TOUS les suffixes SHA-1 commençant par "CBFDA" (environ 400-600 hashes)
Chercher localement si le reste du hash ("C6008F9CAB4083784CBD1874F76618D2A97") est dans la liste
Si trouvé : le mot de passe a été compromis (HIBP retourne aussi le nombre de fuites)

6.2 Implémentation dans Time2Crack (app.js)

La vérification HIBP est asynchrone et non bloquante. Le mot de passe est analysé immédiatement par les méthodes locales, et la vérification HIBP complète le résultat :

// Pseudo-code simplifié
async function checkHIBP(password) {
  const sha1 = await sha1Hash(password);
  const prefix = sha1.substring(0, 5);   // 5 premiers chars
  const suffix = sha1.substring(5);       // reste du hash
const response = await fetch(
    https://api.pwnedpasswords.com/range/${prefix}
  );
  const lines = await response.text();
for (const line of lines.split('\n')) {
    const [hashSuffix, count] = line.split(':');
    if (hashSuffix.toLowerCase() === suffix.toLowerCase()) {
      return parseInt(count);  // nombre de fuites
    }
  }
  return 0;  // non trouvé
}

6.3 Interprétation du count HIBP

Le count retourné par HIBP indique le nombre de fois que ce mot de passe exact est apparu dans des fuites indexées :

Même un count de 1 (le mot de passe n'est apparu qu'une seule fois dans une fuite) indique une vulnérabilité : si un attaquant cible ce compte spécifiquement et dispose de la liste de credentials de la fuite en question, il le trouvera.

7. Les wordlists linguistiques de Time2Crack

7.1 Pourquoi des wordlists linguistiques en complément de HIBP

HIBP couvre les credentials compromis exacts — mais pas les mots courants jamais encore fuités. Un utilisateur francophone qui choisit "éphémère" comme mot de passe n'est peut-être pas dans HIBP (le mot est peu probable dans des credentials anglophones), mais il est dans la wordlist française de tout attaquant ciblant un système francophone.

Les wordlists linguistiques de Time2Crack couvrent cette lacune :

7.2 Chargement paresseux (lazy-loading)

Les wordlists ne sont pas intégrées dans le code — elles sont chargées à la demande lors du changement de langue, pour respecter le budget réseau :

// app.js - loadDictionary()
async function loadDictionary(lang) {
  if (DICTLANG === lang && DICTWORDS) return;  // Déjà chargé
  if (DICTLOADING) {
    DICTPENDINGLANG = lang;  // File d'attente
    return;
  }
  DICTLOADING = true;
const res = await fetch(data/wordlists/${lang}.txt);
  const text = await res.text();
// Conversion en Set<string> pour O(1) lookup
  DICTWORDS = new Set(
    text.split("\n")
        .map(w => w.normalize("NFC").trim().toLowerCase())
        .filter(w => w.length >= 4)
  );
  DICTLANG = lang;
  DICTLOADING = false;
}

7.3 File d'attente de chargement

Le mécanisme de DICTPENDINGLANG évite les race conditions lors de changements rapides de langue :

Scénario : l'utilisateur switche rapidement EN → FR → DE
├── EN demandé : DICTLOADING = false → début du fetch EN
├── FR demandé pendant fetch EN : DICTLOADING = true → DICTPENDINGLANG = "fr"
├── DE demandé pendant fetch EN : DICTLOADING = true → DICTPENDINGLANG = "de" (écrase "fr")
├── Fetch EN termine : DICTLANG = "en", puis lance loadDictionary("de")
└── Résultat : seule la dernière langue demandée est chargée

Ce comportement est intentionnel : on charge la langue la plus récemment demandée, pas toutes les langues intermédiaires.

8. Détection dictionnaire dans Time2Crack : isDictWord()

8.1 Fonctionnement de la détection

La fonction isDictWord(pw) détermine si un mot de passe est ou dérive d'un mot du dictionnaire courant :

// app.js - ligne 2181
function isDictWord(pw) {
  if (!DICTWORDS) return false;
// Normalisation : NFC + lowercase
  const l = pw.normalize("NFC").toLowerCase();
// Vérification directe
  if (DICTWORDS.has(l) || DICTWORDS.has(deLeet(pw))) return true;
// Variations morphologiques
  const deleetWord = deLeet(pw);
  const variations = getMorphVariations(deleetWord);
for (const variation of variations) {
    if (DICTWORDS.has(variation)) return true;
  }
return false;
}

8.2 Normalisation Unicode (NFC)

La normalisation normalize("NFC") garantit que les caractères accentués sont traités de façon cohérente :

Cette normalisation est appliquée à la fois lors de la création du dictionnaire et lors de la vérification — garantissant des correspondances correctes pour les langues à accents (FR, ES, DE, PT, etc.).

8.3 Impact sur la vulnérabilité détectée

Quand isDictWord() retourne true, plusieurs attaques deviennent applicables :

9. De-leetification : comment l'attaquant décode les substitutions

9.1 Le leetspeak et ses limites comme protection

Le leetspeak (ou "1337 speak") est une pratique consistant à substituer des lettres par des chiffres ou symboles visuellement similaires : a→@, e→3, i→1 ou !, o→0, s→$. Les utilisateurs l'emploient pour "renforcer" des mots courants.

La réalité : ces substitutions sont les premières règles appliquées dans toute attaque dictionnaire avec règles de mutation. Elles ne constituent pas une défense réelle contre un attaquant compétent.

9.2 Implémentation de deLeet() dans Time2Crack

// app.js - ligne 3622
const LEETBASE = {
  a: ["@", "4"],
  e: ["3"],
  o: ["0"],
  s: ["$", "5"],
  t: ["+", "7"],
  h: ["#"],
  g: ["9"],
};
function deLeetWith(pw, oneMap) {
  let r = pw.normalize("NFC").toLowerCase();
  for (const [ch, reps] of Object.entries(LEETBASE))
    for (const c of reps) r = r.split(c).join(ch);
  // Appliquer la résolution ambiguë (i ou l) en dernier
  for (const [ch, reps] of Object.entries(oneMap))
    for (const c of reps) r = r.split(c).join(ch);
  return r;
}
function deLeet(pw) {
  // Ambiguïté : "1" peut être "i" ou "l"
  const withI = deLeetWith(pw, { i: "1!", l: "" });
  const withL = deLeetWith(pw, { l: "1", i: "!" });
// Si le dictionnaire est chargé, préférer la variante qui matche
  if (DICTWORDS) {
    if (DICTWORDS.has(withL)) return withL;
    if (DICTWORDS.has(withI)) return withI;
  }
// Sinon : préférer la variante avec le moins de chiffres restants
  const digitsI = (withI.match(/\d/g) || []).length;
  const digitsL = (withL.match(/\d/g) || []).length;
  return digitsL <= digitsI ? withL : withI;
}

9.3 Gestion de l'ambiguïté "1" → "i" ou "l"

La substitution "1" est ambiguë : "1" peut représenter "i" (comme dans "1nfo" → "info") ou "l" (comme dans "p1ayer" → "player"). Time2Crack résout cette ambiguïté en :

9.4 Substitutions non couvertes (intentionnellement)

Time2Crack ne couvre pas les substitutions rares ou ambiguës au-delà des patterns LEETBASE. C'est un choix de conception : couvrir trop de cas augmenterait les faux positifs (détecter un mot de passe comme "mot courant" alors qu'il ne l'est pas). Les patterns inclus couvrent >95% des leetifications réelles observées dans les corpus.

10. Calcul du temps de cracking : addDictionaryAttacks()

10.1 Logique de calcul

// app.js - ligne 3848
function addDictionaryAttacks(rows, common, weak, dictWord) {
  for (const a of ALGOS) {
    let sec;
    if (weak)     sec = 100 / a.rate;     // Top ~100 entrées
    else if (common) sec = 10000 / a.rate; // HIBP priority list ~10k
    else if (dictWord) sec = 200000 / a.rate; // Scan wordlist complète ~200k mots
    else sec = null;                        // Non applicable
const note = weak    ? t("nWeakPassword")
               : common  ? t("nInLeaks")
               : dictWord ? t("nDictHit")
               : t("nAbsentLeaks");
rows.push({ atk: t("aDict"), hash: a.name, rate: a.rate, sec, note, cat: "dict" });
  }
}

10.2 Les trois niveaux de vulnérabilité

10.3 Pourquoi ces nombres (100, 10 000, 200 000) ?

Ces valeurs sont calibrées sur des données réelles :

10.4 Exemple numérique complet

Pour le mot de passe "soleil" (mot français courant, détecté comme dictWord) :

Même pour Argon2id, 250 secondes représente moins de 5 minutes — pour un simple mot du dictionnaire français.

11. Calibration haute fidélité : applyHighFidelityCalibration()

11.1 Pourquoi une calibration supplémentaire ?

Le calcul brut de addDictionaryAttacks() donne une estimation du "pire cas" — comme si l'attaquant testait uniformément toute la wordlist. En réalité, les listes d'attaque sont ordonnées par probabilité : les passwords les plus communs arrivent en premier.

La calibration haute fidélité applique un multiplicateur correctif basé sur des observations empiriques :

// app.js - ligne 4442
case "dict":
  // Ur et al. 2012 : mots communs trouvés dans les 100-10k premiers essais
  // Weir 2009 : mots dict trouvés dans les 200k premiers essais (scan ordonné)
  m = context.common ? 0.15 : context.dictWord ? 0.5 : 1.0;
  break;

11.2 Sources académiques de la calibration

12. Probabilité d'applicabilité et score de confiance

12.1 Système de scoring

Time2Crack ne se contente pas de calculer un temps — il évalue aussi la probabilité que l'attaque dictionnaire soit réellement l'attaque la plus rapide, via un système de scoring multi-facteurs :

// Score d'applicabilité (0-1)
case "dict":
  return context.common ? 0.99 : context.dictWord ? 0.85 : 0;

12.2 Score d'evidence

En parallèle du score d'applicabilité, un score "d'evidence" comptabilise les signaux observés :

case "dict":
  return Number(!!context.common) + Number(!!context.dictWord);
  // 0 : aucun signal
  // 1 : un signal (common OU dictWord)
  // 2 : deux signaux (common ET dictWord)

Un score d'evidence de 2 (mot à la fois dans HIBP et dans le dictionnaire linguistique) boost la confiance finale de 0,08 (2 × 0,04).

12.3 Score de confiance final

const base = confidenceBase["dict"] || 0.6;  // confiance de base
const evidenceBoost = Math.min(0.12, row.evidenceScore  0.04);
const speculativePenalty = speculativeCats.has("dict") ? 0.08 : 0;  // dict n'est pas spéculatif
row.confidence = Math.max(0, Math.min(1,
  Math.max(applicability, base) + evidenceBoost - speculativePenalty
));

Pour un password common avec dictWord également détecté :

Confiance maximale : l'attaque dictionnaire est l'attaque primaire sans ambiguïté.

13. Bloom filter RockYou : détection locale des mots de passe répandus

13.1 Contexte

En complément de la vérification HIBP (qui nécessite un appel réseau), Time2Crack intègre un bloom filter du corpus RockYou chargeable localement. Un bloom filter est une structure de données probabiliste qui permet de tester l'appartenance à un ensemble avec une probabilité de faux positifs paramétrable (~1%), sans stocker les éléments eux-mêmes.

13.2 Avantages du bloom filter

13.3 Fonctionnement du double-hashing

// app.js - ligne 1962
function bloomHas(filter, word) {
  if (!filter) return false;
  const { bitArray, m, k } = filter;
  const w = word.toLowerCase();
// Double-hashing : h1 et h2 sont deux fonctions hash indépendantes
  const h1 = fnv1a32(w, 2166136261);   // FNV1a avec seed standard
  const h2 = fnv1a32(w, 0x811c9dc5);   // FNV1a avec seed alternatif
for (let i = 0; i < k; i++) {
    const pos = (h1 + ((i  h2) >>> 0)) % m;  // k positions dans le tableau de bits
    const byteIdx = Math.floor(pos / 8);
    const bitIdx = pos % 8;
// Si un bit est à 0 : le mot est DÉFINITIVEMENT absent
    if ((bitArray[byteIdx] & (1 << bitIdx)) === 0) return false;
  }
  // Tous les bits sont à 1 : le mot est PROBABLEMENT présent (avec 1% de FP)
  return true;
}

Le double-hashing FNV1a garantit une distribution uniforme des positions dans le tableau de bits, minimisant les collisions et maintenant le taux de faux positifs proche de 1%.

13.4 Chargement et format binaire

Le bloom filter est stocké dans data/rockyou.bloom — un fichier binaire avec :

Le chargement est déclenché manuellement par l'utilisateur (bouton dans l'UI), pas automatiquement au chargement de la page — pour préserver les performances initiales.

14. Comparaison avec les attaques dérivées

L'attaque dictionnaire "pure" est la première d'une famille d'attaques qui partagent toutes une racine commune : une wordlist lexicale. Time2Crack implémente 7 modèles de cracking hors ligne (brute force, dictionnaire, hybride, masque, PCFG, Markov, combinator), chacun attaquant le mot de passe sous un angle différent.

14.1 Dictionnaire vs Hybride

L'attaque hybride commence là où le dictionnaire pur s'arrête : elle prend chaque mot de la wordlist et lui applique des règles de mutation systématiques (hashcat "best64.rule" en tête).

14.2 Dictionnaire vs PCFG

Un mot de passe comme "Password123" peut passer inaperçu dans un dictionnaire (le mot exact "Password123" n'est peut-être pas listé) mais sera craqué très rapidement par PCFG qui reconnaît la structure [Majuscule][minuscules][chiffres].

14.3 Dictionnaire vs Markov

Le Markov couvre les cas où le mot de passe ressemble à un mot humain sans être dans aucune liste.

14.4 Dictionnaire vs Credential Stuffing

Le credential stuffing n'attaque pas un hash — il essaie directement des paires login/mot de passe sur des services distants. C'est conceptuellement différent du cracking, mais partage la même source de données (HIBP/fuites).

15. Limites de l'attaque dictionnaire

15.1 Limites intrinsèques

15.2 Ce que le calcul de Time2Crack ne modélise pas

16. Défenses efficaces

16.1 Ce qui protège contre l'attaque dictionnaire

La différence de 10+ ordres de grandeur entre MD5 et Argon2id rend le mot de passe dictionnaire "soleil" immunisé en pratique si protégé par Argon2id — même si l'attaquant sait que c'est un mot français.

16.2 Ce qui ne protège pas

16.3 Recommandations pratiques

17. Références bibliographiques

Sources primaires (études académiques)