Janvier 2024 : quand Microsoft se fait pirater par un compte test sans MFA

En janvier 2024, Microsoft a révélé avoir été compromis par le groupe russe Midnight Blizzard (APT29, lié au SVR). Le vecteur d'attaque ? Un compte de test obsolète sans authentification multifacteur, utilisé comme pivot pour accéder aux boîtes mail de membres de la direction, dont l'équipe de cybersécurité elle-même. Si Microsoft, avec ses milliers d'ingénieurs sécurité, peut se faire piéger par un compte oublié sans MFA, imaginez ce que cela signifie pour les PME.

Dans le même temps, 23andMe confirmait la fuite de données de 6,9 millions de comptes — non pas via une faille technique sophistiquée, mais par credential stuffing : les attaquants ont testé des identifiants issus d'autres fuites sur la plateforme. En juillet 2024, RockYou2024 rendait publique une compilation de 10 milliards de mots de passe issus de fuites historiques. La matière première des attaques par credential stuffing n'a jamais été aussi abondante.

Ces trois événements partagent un dénominateur commun : des pratiques d'authentification insuffisantes. Chez ADRD Consulting, nous avons codifié un protocole d'authentification PHP que nous appliquons systématiquement sur tous nos projets — RecruteX, MailGuard, QualiTrack, ADRD Remote. Voici ce protocole, avec le code exact.

1. Hachage des mots de passe : bcrypt coût 12, pas moins

La première erreur des développeurs PHP est d'utiliser md5() ou sha1(). Ces algorithmes sont conçus pour la vitesse — exactement le contraire de ce qu'on veut pour les mots de passe. Un GPU moderne peut calculer 10 milliards de SHA-1 par seconde. Avec bcrypt coût 12, ce chiffre tombe à quelques dizaines par seconde, rendant les attaques par force brute économiquement non viables.

// ✅ Standard ADRD — bcrypt coût 12
$hash = password_hash($motDePasse, PASSWORD_BCRYPT, ['cost' => 12]);

// ✅ Vérification
if (password_verify($motDePasse, $hashEnBase)) {
    // Connexion autorisée — passer à session_regenerate_id IMMÉDIATEMENT
}

// ✅ Rehash automatique si le coût évolue
if (password_needs_rehash($hash, PASSWORD_BCRYPT, ['cost' => 12])) {
    $nouveauHash = password_hash($motDePasse, PASSWORD_BCRYPT, ['cost' => 12]);
    // Mettre à jour en BDD
}

Le coût 12 induit environ 250 ms de calcul, ce qui est imperceptible pour un utilisateur humain mais multiplie par 10 000 le coût d'une attaque automatisée comparé au coût 8.

2. Comparaison timing-safe avec hash_equals()

Une subtilité que la majorité des développeurs ignore : comparer deux chaînes avec === est vulnérable aux attaques temporelles. PHP s'arrête à la première différence de caractère, ce qui permet à un attaquant mesurant les temps de réponse de deviner le token caractère par caractère. La solution : hash_equals(), qui prend toujours le même temps quelle que soit la différence.

// ❌ Vulnérable aux timing attacks
if ($tokenSoumis === $tokenEnBase) { /* ... */ }

// ✅ Timing-safe — Standard ADRD
if (hash_equals($tokenEnBase, $tokenSoumis)) { /* ... */ }

Chez ADRD, cette règle est absolue : hash_equals() sur tous les tokens (réinitialisation de mot de passe, validation email, CSRF, API keys).

3. session_regenerate_id(true) immédiatement après le login

La fixation de session est une attaque permettant à un attaquant de prédéfinir l'ID de session d'une victime avant son authentification. La contre-mesure est simple mais souvent oubliée : régénérer l'ID de session dès que le niveau de privilège change.

// ✅ Obligatoire après chaque login réussi
session_start();
// ... vérification mot de passe ...
session_regenerate_id(true); // true = supprimer l'ancienne session
$_SESSION['user_id'] = $utilisateur['id'];
$_SESSION['role'] = $utilisateur['role'];
$_SESSION['login_time'] = time();

4. Cookies sécurisés : httponly, secure, samesite

Si votre cookie de session est accessible via JavaScript, une faille XSS suffit à voler toutes vos sessions actives. Configuration obligatoire :

// Dans php.ini ou en début de script
ini_set('session.cookie_httponly', 1);    // Inaccessible JS
ini_set('session.cookie_secure', 1);      // HTTPS uniquement
ini_set('session.cookie_samesite', 'Strict'); // Protection CSRF
ini_set('session.use_strict_mode', 1);    // Rejette les IDs non initialisés
ini_set('session.cookie_lifetime', 0);    // Session expire à la fermeture navigateur

5. Rate limiting sur les tentatives de connexion

L'attaque de credential stuffing qui a frappé 23andMe était possible parce que la plateforme n'avait pas de rate limiting efficace. Notre implémentation ADRD : 5 tentatives maximum sur 5 minutes, stockées en base avec IP + user agent.

function verifierRateLimit(PDO $pdo, string $ip): bool {
    $stmt = $pdo->prepare(
        "SELECT COUNT(*) FROM login_attempts
         WHERE ip = ? AND created_at > DATE_SUB(NOW(), INTERVAL 5 MINUTE)"
    );
    $stmt->execute([$ip]);
    return $stmt->fetchColumn() < 5;
}

function enregistrerTentative(PDO $pdo, string $ip, bool $succes): void {
    $stmt = $pdo->prepare(
        "INSERT INTO login_attempts (ip, success, created_at) VALUES (?, ?, NOW())"
    );
    $stmt->execute([$ip, $succes ? 1 : 0]);
}

6. Mots de passe générés : jamais de générique, always must_change

Quand un administrateur crée un compte, la tentation est de mettre un mot de passe par défaut comme Admin123!. Chez ADRD, c'est interdit. Nous générons un mot de passe aléatoire fort et forçons le changement dès la première connexion :

// Génération d'un mot de passe temporaire fort
function genererMotDePasseTemp(int $longueur = 16): string {
    $chars = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!@#$%';
    return substr(str_shuffle(str_repeat($chars, ceil($longueur / strlen($chars)))), 0, $longueur);
}

// En BDD
$mdpTemp = genererMotDePasseTemp();
$hash = password_hash($mdpTemp, PASSWORD_BCRYPT, ['cost' => 12]);
$pdo->prepare("INSERT INTO users (email, password, must_change_password) VALUES (?, ?, 1)")
    ->execute([$email, $hash]);

La leçon de Midnight Blizzard pour les PME

Le compte test Microsoft compromis avait probablement un mot de passe faible, pas de MFA, et n'avait jamais été audité. Combien de vos applications ont des comptes de test, des comptes de démonstration, ou des comptes créés "temporairement" et jamais supprimés ? L'audit régulier des comptes actifs fait partie du protocole ADRD autant que le code.

Checklist ADRD — Authentification PHP :

Votre application PHP mérite mieux que les statistiques de 2024. Contactez ADRD Consulting pour un audit de votre système d'authentification.