D’abord la conclusion. Un SHA-256 restant répond à la question : une fois le hash emporté, chaque essai est-il bon marché. Un mot de passe réutilisé répond à une autre : il n’y a rien à deviner. Se retrouver hors du pare-feu signifie que quelqu’un a modifié le compte d’origine après l’intrusion. L’algorithme ne verrouille pas la porte tout seul. Après un FortiOS qui prend en charge PBKDF2, l’ancien hash ne bascule vers le nouveau schéma qu’au moment où l’administrateur concerné se connecte avec succès, ou qu’un super-administrateur réinitialise le mot de passe. Pour pouvoir redescendre de version plus tard, l’ancien SHA-256 reste par défaut dans un champ masqué.
Répondre d’abord à l’intention de recherche
Qui cherche « FortiBleed », « administrateur exclu du pare-feu » ou « mot de passe stocké en SHA-256 » a trois faits déjà empilés dans la même dépêche, et il faut les séparer. Premier fait : l’attaquant reprend des mots de passe issus d’anciennes fuites ou de journaux de logiciels voleurs, et les essaie directement sur des SSL VPN FortiGate encore exposés. Deuxième fait : si l’appareil conserve encore ce que le fabricant appelle un stockage SHA-256 hérité pour le mot de passe administrateur, le hash, une fois copié, peut être deviné hors ligne sur un parc de GPU. Troisième fait : une fois entré, l’autre crée des comptes, puis change ou supprime l’administrateur d’origine. La personne légitime n’ouvre plus le portail.
Cette note s’adresse à l’exploitation qui tient encore des comptes de pare-feu ou de VPN, et au collègue à qui l’on a demandé de « changer tous les mots de passe administrateur ce soir ». Elle ne remplace pas la page du générateur de mot de passe, et elle ne présente pas le testeur de mot de passe comme un outil capable de dire si cet appareil figure dans FortiBleed. Ce qu’il faut emporter : ce qu’un hash rapide, une dérivation de clé lente, un mot de passe réutilisé et un compte supprimé empêchent chacun, et quels deux marqueurs, dans une sauvegarde de configuration, se vérifient sur place.
Ce que l’avis du 6 octobre dit vraiment
L’avis conjoint du FBI et du Secret Service des États-Unis, daté du 6 octobre 2026 (référence JCSA-20261006-01, marqué TLP:CLEAR) nomme l’opération FortiBleed. La cible est le pare-feu Fortinet FortiGate et la passerelle SSL VPN exposés à Internet. L’avis cite un décompte vérifié par SOCRadar : plus de 86 644 appareils, dans 194 pays. Il écrit que l’attaque s’appuie sur des mots de passe réutilisés ou déjà divulgués, et sur un stockage de mot de passe SHA-256 hérité, pour emporter des lots de matériel d’authentification puis les casser. Le constat préliminaire est que les attaquants continuent de balayer les pare-feu Fortinet exposés avec des mots de passe obtenus auparavant.
Le même document décrit un répertoire backend de l’attaquant qui s’est lui-même retrouvé exposé, ce qui a rendu la chaîne d’outils visible. Après avoir trouvé un portail SSL VPN FortiGate, le bourrage d’identifiants reprend d’anciennes bases de fuites Fortinet et des journaux de logiciels voleurs de mots de passe. L’aspersion de mots de passe (password spraying) est aussi décrite. Les hash extraits partent vers un parc de GPU piloté par Hashcat et Hashtopolis, pour un cassage hors ligne. Les résultats sont filtrés, vérifiés, puis utilisés pour créer de nouveaux comptes administrateur sur le pare-feu. L’avis présente la suite comme une revente d’accès initial, et écrit que cette chaîne a été observée remise à des affiliés de rançongiciels, en nommant notamment INC/Lynx et Payload. Le niveau de preuve de ces phrases est « l’avis l’écrit ainsi ». Cette note n’a pas refait l’investigation.
Ce qui contredit directement « changer un mot de passe et c’est fini », c’est la section de l’avis sur l’exclusion. D’après les premières réponses, si l’autre supprime le compte d’origine ou en change le mot de passe, l’organisation découvre qu’elle ne peut plus se connecter à l’équipement Fortinet. Pendant l’intrusion, l’attaquant crée des comptes qui n’existaient pas. Dans certains cas, supprimer les comptes existants sert à bloquer l’accès de l’organisation elle-même, tout en poursuivant le déplacement latéral. L’avis écrit donc que le traitement peut devoir aller au-delà du correctif habituel et de la réinitialisation des mots de passe. Il rattache cette étape à la technique MITRE ATT&CK T1531 (Account Access Removal).
Cette note ne fournit ni extraction de hash, ni dictionnaire, ni commande de cassage, et elle ne recopie pas les listes d’adresses et de noms de comptes de l’avis. Ces listes servent aux équipes qui examinent déjà leurs journaux. Les vérifications ci-dessous n’utilisent que l’équipement que vous êtes autorisé à administrer, et la documentation publique du fabricant. Ne téléchargez pas un répertoire ouvert d’origine inconnue « pour vérifier la nouvelle », et ne collez pas une sauvegarde de configuration qui contient des hash de mots de passe dans un ticket ou une fenêtre de conversation.
Un mot de passe réutilisé et un cassage hors ligne ne sont pas le même chemin
Un titre de dépêche ramène facilement tout à « le mot de passe était trop faible ». L’avis décrit au moins deux chemins indépendants, avec des conditions d’échec différentes. Le bourrage d’identifiants et l’aspersion se produisent à la connexion, en ligne. L’autre soumet un clair qu’il connaît déjà, ou qu’il est en train d’essayer. L’algorithme avec lequel l’appareil stocke le mot de passe n’influence alors que la comparaison faite par l’appareil. Il ne change pas la chaîne que l’autre a déjà en main. Si cette chaîne est identique à un compte VPN ou administrateur encore valide, la connexion réussit.
Le cassage hors ligne commence après que le hash a été copié. L’autre ne frappe plus votre portail. Il énumère des essais sur ses propres machines, transforme chaque essai en hash, et compare au matériel copié. Le coût de cette étape dépend du travail que le schéma de stockage impose à chaque essai, et de la taille de l’espace de recherche du mot de passe lui-même. SHA-256 est une fonction de hachage rapide, conçue pour l’intégrité : la même entrée donne toujours la même sortie, et un seul calcul suffit. Elle convient pour contrôler un fichier. Elle ne convient pas, seule, à faire payer un prix visible à chaque essai de mot de passe. Un parc de GPU loué sert précisément à exécuter en parallèle ce calcul qui se termine en une passe. Hashtopolis, dans l’avis, répartit les tâches de cassage sur plusieurs machines. Ce n’est pas un nouvel algorithme de chiffrement.
| Chemin | Ce que l’autre a en main | Après un passage du stockage à PBKDF2 |
|---|---|---|
| Bourrage d’identifiants / aspersion | Le clair, ou une très courte liste de mots courants | Le clair se connecte encore directement ; une dérivation lente n’arrête pas un mot de passe déjà connu |
| Cassage hors ligne | Le hash de mot de passe copié depuis l’appareil | Chaque essai devient plus cher ; un mot de passe court ou réutilisé peut encore être trouvé |
| Exclusion | Une session d’administration déjà ouverte | Changer ou non l’algorithme n’empêche pas de modifier ou de supprimer le compte d’origine |
La troisième ligne du tableau bloque une lecture fréquente : écrire « nous sommes passés à un hash plus lent » comme si cela voulait dire « l’administrateur ne sera plus laissé dehors ». L’exclusion se produit après que l’authentification a déjà réussi. Elle dépend de la capacité de l’autre à modifier la configuration. Elle ne dépend pas de la vitesse de SHA-256. Dans l’autre sens, se contenter de réinitialiser les mots de passe, sans retirer l’administration exposée à Internet et sans ajouter une authentification multifacteur résistante au hameçonnage, ne traite qu’une partie de ce que l’avis énumère. Le FBI et le Secret Service placent dans le même groupe de mesures : resserrer l’accès d’administration, terminer les sessions d’administration et les sessions VPN en cours, réinitialiser les mots de passe, activer une authentification multifacteur résistante au hameçonnage, contrôler les comptes inconnus, et confirmer PBKDF2.
Ce que prouvent SHA-256 et PBKDF2, chacun de son côté
La Password Storage Cheat Sheet de l’OWASP sort le stockage des mots de passe du modèle « calculer une fois un hash rapide ». Il faut une dérivation de clé lente, avec un sel unique : Argon2id, bcrypt, scrypt, ou PBKDF2 avec assez d’itérations. Le sel empêche une table précalculée de passer d’une personne à la suivante. Les itérations, ou un paramètre coûteux en mémoire, font répéter beaucoup de travail à chaque essai. Les deux ne répondent pas à la même question. Un sel seul, avec un seul calcul SHA-256, met les tables arc-en-ciel hors jeu, mais l’énumération GPU d’un mot de passe court reste bon marché. Une dérivation lente avec le même sel pour tout le monde laisse encore une seule table couvrir un grand lot de hash. L’avis ne décrit pas l’ancien schéma Fortinet comme « entièrement sans sel ». Cette note ne comble pas ce détail. Ce qui peut entrer dans une phrase, c’est la comparaison que le fabricant a publiée ensuite.
La note technique Fortinet sur le hash des mots de passe administrateur indique qu’à partir de FortiOS 7.2.11, 7.4.8 et 7.6.1, le hash qui conserve les identifiants d’administrateur du pare-feu dans la configuration passe de SHA256 à PBKDF2. La note utilise SH2 pour SHA256 et PB2 pour PBKDF2. En dessous de ces seuils, la même note marque encore la fonction de hachage comme SHA256. Les notes de version 7.2.11 décrivent le nouveau schéma comme un PBKDF2 avec sel aléatoire, pour renforcer le stockage du mot de passe des administrateurs locaux du système. Ce n’est pas la même phrase que « la page affiche chiffré ». SHA-256 et PBKDF2 sont ici des dérivations à sens unique. Aucun des deux n’enveloppe le mot de passe dans un texte chiffré réversible avec une clé symétrique. Voir SH2 ne se lit pas comme « le disque contient le clair ». Voir PB2 ne se lit pas comme « un clair déjà divulgué n’a plus d’importance ».
PBKDF2 n’a pas un nombre d’itérations « déjà assez lent » valable pour le monde entier. La documentation du fabricant publie le nom de l’algorithme, le sel, et les marqueurs SH2 / PB2 dans la configuration. Les notes citées ci-dessus ne donnent pas un entier d’itérations que l’on pourrait recopier dans un ticket. Écrire « dans cette sauvegarde, ce compte est déjà en PB2 » reste plus proche de ce que le document permet que « donc un GPU ne peut pas le casser ». Un mot de passe court, ou recopié depuis une ancienne fuite, reste une devinette à bas coût même avec un nombre d’itérations limité. Un mot de passe aléatoire, long, et différent pour chaque compte, agrandit l’espace de recherche. Il ne ferme pas l’interface d’administration exposée à Internet.
La mise à jour ne remplace pas l’ancien hash avant la connexion
La phrase la plus facile à manquer dans la note technique est celle-ci : lors d’une mise à jour depuis une version plus ancienne, le mot de passe administrateur reste stocké en SHA256 jusqu’à ce que cet administrateur se connecte avec succès sur le nouveau firmware. Pour que tous les administrateurs locaux passent à PBKDF2, chacun doit se connecter au moins une fois. Ceux qui ne se sont pas connectés doivent voir leur mot de passe mis à jour à la main par super_admin. Inscrire le numéro de version du firmware dans un ticket de changement ne prouve pas que la configuration ne contient plus de SH2.
Même lorsque le champ du mot de passe courant est déjà en PBKDF2, l’ancien hash ne disparaît pas tout seul. La note l’écrit : pour la compatibilité descendante, le SHA256 précédent reste par défaut dans le réglage masqué old-password. L’interface d’administration après une connexion ordinaire ne montre pas ce champ. Une sauvegarde de configuration exportée par super_admin le montre. Tant que cet ancien matériel est dans la sauvegarde, la cible du cassage hors ligne est encore là. L’attaquant n’a pas besoin d’attendre la fin de votre mise à jour de firmware pour l’emporter. Si le fichier de sauvegarde lui-même part dans un disque en ligne, un ticket ou une conversation, vous venez de copier SH2 une fois de plus.
Retirer le SH2 de old-password passe par un autre interrupteur. Ce n’est pas un effet de bord de la mise à jour. Sur FortiOS 7.2.x et 7.4.x, le réglage correspondant est login-lockout-upon-downgrade. Un autre nom, dans la documentation ultérieure, est login-lockout-upon-weaker-encryption. L’activer affiche un avertissement de confirmation. Les notes de version indiquent que PBKDF2 est disponible à partir de 7.2.11, 7.4.8 et 7.6.1. Si l’on redescend ensuite vers une version qui ne prend pas en charge ce hash, les administrateurs locaux ne pourront plus se connecter. Un chemin comme 7.2.11 vers 7.4.7 — numéro de version plus élevé, mais encore sans PBKDF2 — entre aussi dans ce verrou. Les administrateurs authentifiés par LDAP, RADIUS ou SAML n’utilisent pas ce jeu de hash locaux, et ce verrou de retour en arrière ne les concerne pas. Les comptes locaux sont le sujet des marqueurs SH2 / PB2.
Activer « effacer l’ancien hash » et « nous devrons peut-être revenir en arrière ce soir » se contredisent donc. Le jour de l’incident, si la version de firmware qui restera en place parmi celles qui prennent en charge PBKDF2 n’est pas encore choisie, n’ouvrez pas ce verrou seulement pour faire disparaître SH2. Gardez d’abord un chemin pour entrer dans l’appareil. Effacez l’ancien matériel une fois certain qu’il n’y aura pas de retour en arrière. Quand l’avis recommande de « confirmer l’usage de PBKDF2 et de retirer les hash hérités plus faibles », il renvoie à cette note du fabricant. Ce n’est pas un synonyme de « changer une fois le mot de passe sur le portail ».
L’exclusion arrive après une connexion déjà réussie
La première réaction, en lisant la dépêche, est souvent de réinitialiser tous les mots de passe administrateur. Une réinitialisation invalide un ancien clair que l’autre n’a pas encore eu le temps d’utiliser. Si vous pouvez encore entrer, elle peut aussi faire passer le stockage de SH2 à PB2. Elle ne traite pas le cas « l’autre s’est déjà connecté avec votre compte et a modifié le compte lui-même ». L’avis décrit la suppression ou le changement du mot de passe du compte d’origine, de sorte que l’administrateur légitime ne peut plus se connecter, en même temps que la création de comptes qui n’existaient pas, pour conserver son propre accès. Un échec d’authentification sur le portail VPN prouve alors que « ces identifiants ne sont plus acceptés par l’appareil ». Il ne prouve pas que « l’autre n’a pas de nouveau compte ».
Le ticket gagne donc à être coupé en deux colonnes. Une colonne pour le mot de passe et le hash : pour chaque administrateur local, est-ce SH2 ou PB2 maintenant, la sauvegarde contient-elle encore old-password, et le nouveau mot de passe est-il réutilisé avec la messagerie, la console cloud ou un autre VPN. Une colonne pour l’inventaire des comptes : y a-t-il des administrateurs locaux qui n’existaient pas avant l’avis, toutes les sessions en cours ont-elles été terminées, et l’interface d’administration est-elle encore ouverte à n’importe quelle adresse sur Internet. Une authentification multifacteur résistante au hameçonnage fait qu’un mot de passe seul ne suffit plus à ouvrir l’administration distante et le VPN. Elle ne supprime pas un nouveau compte déjà écrit dans la configuration, et elle ne retire pas un ancien hash déjà copié de la file d’attente GPU de l’autre.
La phrase sur les rançongiciels ne doit pas non plus être lue en avance. L’avis parle d’un accès initial transmis plus loin. Il ne dit pas que chaque pare-feu encore en SHA-256 sera chiffré aujourd’hui. Un appareil sur lequel vous ne pouvez plus vous connecter se traite comme un appareil dont l’intégrité n’est pas confirmée : isoler, contrôler la configuration et les comptes, puis seulement parler de restauration. Un appareil sur lequel vous pouvez encore entrer : retirer d’abord l’administration exposée à Internet, terminer les sessions, faire passer à PB2 les administrateurs locaux encore en SH2, et conserver le nouveau mot de passe à part. Dans les deux cas, n’écrivez pas la même nouvelle chaîne dans une annonce de groupe.
Vérifier sur l’appareil : les marqueurs de la sauvegarde
Le numéro de version, le titre de la dépêche et les trois mots « déjà mis à jour » ne remplacent pas le marqueur de hash de cette configuration. Les quatre étapes ci-dessous supposent que vous êtes déjà un administrateur autorisé de cet appareil. N’ouvrez pas la sauvegarde sur un ordinateur dont vous ne répondez pas, et ne l’envoyez pas dans une conversation générative « pour voir s’il y a un SH2 ».
- Comparez la version du firmware aux trois seuils : 7.2.11, 7.4.8 et 7.6.1. En dessous du seuil de la branche concernée, la note du fabricant marque encore le hash des administrateurs locaux comme SHA256. Une version déjà au-dessus du seuil dit seulement que « une nouvelle connexion a une chance d’être écrite en PB2 ». Elle ne dit pas que les anciens comptes ont fini d’être réécrits.
- Exportez une sauvegarde de configuration avec
super_admin, puis cherchez sur placeSH2,PB2etold-password. Vous ne pouvez noter « cette sauvegarde ne montre plus l’ancien SHA-256 » que pour un compte qui n’a quePB2, et pas deold-password. Ne pas voir le champ masqué dans l’interface ne vaut pas « l’ancien hash a été supprimé ». - Listez les administrateurs locaux et marquez ceux qui ne se sont jamais connectés après la mise à jour, et dont le mot de passe n’a pas été réinitialisé par le super-administrateur. La note indique que ces comptes restent en SHA256 jusqu’à une connexion ou une réinitialisation. Ne mélangez pas les comptes authentifiés à distance dans la même conclusion que ce jeu de hash locaux.
- Si vous envisagez d’activer
login-lockout-upon-downgrade(oulogin-lockout-upon-weaker-encryptiondans la documentation), lisez d’abord l’avertissement de verrouillage en cas de retour en arrière dans les notes de version, et confirmez que vous ne reviendrez pas à court terme vers une version sans PBKDF2. Une fois le réglage ouvert, les administrateurs locaux qui n’ont plus que PBKDF2 ne pourront pas se connecter sur ce retour en arrière.
Ces quatre étapes répondent à « comment cette configuration stocke le mot de passe administrateur en ce moment ». Elles ne répondent pas à « la file GPU de l’autre contient-elle une copie plus ancienne ». Une fois le hash sorti de l’appareil, changer le stockage sur place n’annule pas la copie déjà emportée. Ce qui l’annule, c’est de changer le mot de passe lui-même, et de confirmer que le matériel du nouveau mot de passe ne reste pas en SH2 dans old-password. Savoir si l’administration exposée à Internet est fermée se lit dans la politique des interfaces, pas dans le préfixe du hash.
Quatre façons de trop lire l’avis
La première : lire « le firmware est en 7.2.11 ou au-dessus » comme « SHA-256 n’est plus dans la configuration ». La note attache la conversion à la connexion réussie de cet administrateur, ou à une réinitialisation du mot de passe, et laisse l’ancien hash par défaut dans un champ masqué. Le numéro de version est un point de départ. Ce n’est pas une marque de travail terminé.
La deuxième : lire PBKDF2 comme « les mots de passe réutilisés ne marchent plus ». Une dérivation lente augmente le prix unitaire de la devinette hors ligne. Un clair déjà obtenu sur un autre site, dans une ancienne fuite ou dans un journal de logiciel voleur, se soumet tel quel à la connexion. Des mots de passe différents d’un endroit à l’autre bloquent ce chemin. Ils ne remplacent pas le retrait de l’interface d’administration.
La troisième : lire « j’ai changé le mot de passe » comme « l’exclusion n’arrivera pas », ou comme « une exclusion déjà en place se défait avec la même réinitialisation ». Changer le mot de passe suppose que vous pouvez encore soumettre cette modification. Si l’autre a supprimé le compte ou changé le mot de passe, l’échec sur le portail dit seulement que les anciens identifiants ne sont pas acceptés. Le nouveau mot de passe ne supprime pas non plus, tout seul, l’administrateur que l’autre a créé.
La quatrième : lire « cette chaîne n’apparaît pas dans la liste locale de mots de passe faibles » comme « elle n’est pas dans la file de hash de FortiBleed », ou comme « ce pare-feu est déjà en PBKDF2 ». La comparaison à la liste se fait dans l’onglet du navigateur. Le marqueur de hash de l’appareil se lit dans la sauvegarde de configuration. Ces deux preuves ne se tamponnent pas l’une l’autre. Une absence de correspondance peut encore être un long mot de passe réutilisé. Une correspondance dit seulement que la chaîne est trop courante. Elle ne prouve pas, à elle seule, que ce FortiGate a été compromis.
Questions fréquentes
Après une mise à jour vers FortiOS 7.2.11, le SHA-256 disparaît-il tout de suite ?
Non. La note du fabricant indique qu’à partir de 7.2.11, 7.4.8 et 7.6.1, le mot de passe des administrateurs locaux passe à PBKDF2, mais qu’après la mise à jour il reste en SHA256 jusqu’à ce que l’administrateur concerné se connecte avec succès, ou qu’un super_admin réinitialise ce mot de passe. L’ancien hash est encore, par défaut, dans le old-password masqué. Une sauvegarde de configuration de super_admin le montre. L’interface d’administration ordinaire ne le montre pas. Effacer l’ancien hash demande un réglage du type verrouillage en cas de retour en arrière, et implique d’accepter que, sur une version sans PBKDF2, les administrateurs locaux ne pourront plus se connecter.
Une fois passé à PBKDF2, un clair déjà volé sert-il encore ?
Oui. PBKDF2 augmente le coût du cas « hash seul, il faut deviner essai par essai ». Si l’autre a déjà le clair, tiré d’une ancienne fuite ou d’un journal de logiciel voleur sur la machine, il soumet cette chaîne à la connexion. Il n’a pas à casser le hash. Réutiliser le même mot de passe entre la messagerie, le VPN et le compte administrateur n’est pas corrigé par une dérivation lente : la chaîne en clair reste la bonne.
Si vous êtes déjà exclu, changer encore une fois le mot de passe suffit-il ?
Le changement sur le portail suppose que vous pouvez encore vous connecter. L’avis indique que l’autre peut supprimer le compte d’origine ou en changer le mot de passe, de sorte que l’administrateur légitime ne peut plus entrer, tout en créant des comptes qui n’existaient pas. Ce cas se traite comme un appareil dans lequel on n’entre plus : isoler, puis contrôler la configuration. On ne peut pas le résumer à « relancer une réinitialisation de mot de passe ». Changer le mot de passe ne remplace pas non plus un ancien hash que le firmware n’a pas encore converti, ou qui reste dans old-password.
Une liste locale de mots de passe faibles peut-elle prouver que le hash de ce pare-feu n’a pas été cassé ?
Non. La liste locale répond seulement à ceci : cette chaîne figure-t-elle dans la liste publique à haute fréquence de l’onglet courant, ou dans quelques variantes proches. Elle n’interroge pas FortiBleed et ne lit pas la configuration du pare-feu. Une absence de correspondance ne prouve pas que ce mot de passe n’a jamais fuité, et encore moins que le hash de l’appareil est déjà passé à PBKDF2. Une correspondance dit seulement que la chaîne est trop courante : il faut la changer, et ne plus la réutiliser.
Garder le nouveau mot de passe sur cet appareil
Après être passé de SH2 à PB2, il vous faut encore un mot de passe administrateur qui n’a pas déjà servi ailleurs. Cette étape peut se faire dans l’onglet courant avec le générateur de mot de passe de FastPwd. Aucune inscription. Le site n’a pas de coffre de mots de passe. Le mode aléatoire appelle crypto.getRandomValues, sur une longueur de 6 à 128 caractères, 16 par défaut. En dessous de 8, un avertissement indique une sécurité plus faible. Le résultat n’est pas envoyé par défaut. Le générateur ne se connecte pas à votre pare-feu, ne transforme pas SH2 en PB2, et ne ferme pas l’interface d’administration exposée à Internet. Il fournit une chaîne que vous n’avez pas à inventer à partir de « admin / nom de l’entreprise / saison », pour remplacer le compte local dans lequel vous pouvez encore entrer.
Ouvrez Network dans les outils de développement, cochez la conservation du journal, et cherchez la chaîne entière du nouveau mot de passe dans la ligne de requête et dans le corps. Elle ne doit pas apparaître dans une requête métier. Cette étape prouve que, cette fois, la chaîne n’est pas partie comme corps HTTP de l’onglet. Elle ne prouve pas que vous l’avez ensuite collée dans une messagerie. Si le navigateur propose d’enregistrer le mot de passe, refusez. La liste des mots de passe déjà enregistrés dans le navigateur est une autre porte, sans lien avec le PB2 de FortiOS. Un mot de passe aléatoire de 16 caractères, tiré parmi majuscules, minuscules, chiffres et symboles, a un espace de recherche bien plus large que les mots courts habituels de l’aspersion. N’écrivez pas cette phrase comme « donc SHA-256 ne peut absolument pas le calculer », ni comme « donc l’interface d’administration peut rester ouverte sur Internet ».
Si vous voulez aussi voir si une chaîne ressemble à un mot de passe faible de la liste publique à haute fréquence, prenez une autre chaîne jetable et comparez-la dans le testeur de mot de passe. Le mot de passe testé n’est pas envoyé. La comparaison porte sur la liste publique téléchargée avec la page, pas sur Have I Been Pwned, et pas sur la base de hash de FortiBleed. Une absence de correspondance ne prouve pas que le web entier ne l’a jamais vue. Ne collez pas dans le champ de test le mot de passe de pare-feu que vous allez activer, et n’y apportez pas la sauvegarde de configuration.
Si le nouveau mot de passe doit être remis une fois à un autre collègue d’astreinte, ne l’écrivez pas dans un message de groupe ou dans le corps d’un ticket qui reste sur un serveur. Passez par le lien auto-destructeur : le serveur ne conserve que le texte chiffré, de façon temporaire, la clé est placée après le # du lien, et la création comme la lecture se font sans compte. La forme du lien est s.html?id={id}#{key}. Ce canal répond à « comment remettre le secret une fois ». Il ne répond pas à « comment réparer le pare-feu ». Si une sauvegarde de configuration contient SH2 ou old-password, ne placez pas le fichier entier dans un lien auto-destructeur ni sur un disque en ligne. La sauvegarde reste sur une machine à laquelle vous faites déjà confiance, puis se traite selon vos propres règles de conservation des configurations. Une capture d’écran, ou le transfert du lien complet, laisse une copie que la destruction après lecture ne couvre pas.
Pour aller plus loin
Une liste locale de mots de passe faibles peut attraper des mots trop courants, et ne peut pas tenir lieu d’une recherche sur tout le web ni d’une base de hash liée à un incident : voir Ce qu’une liste locale de mots de passe faibles peut prouver, et pourquoi ce n’est pas une recherche sur tout le web. Pour générer un mot de passe, il faut un aléa sûr au sens cryptographique, pas Math.random : voir Pourquoi un mot de passe issu de Math.random peut sembler assez mélangé sans être un aléa cryptographiquement sûr. Quand une clé à usage unique est placée après le dièse d’un lien, le serveur ne reçoit pas ce fragment par défaut : voir Pourquoi un fragment d’URL peut porter une clé, et quand cette protection lâche.