La double authentification est toujours activée après l’incident

Le 10 août 2026, la Fédération française de handball détecte un accès non autorisé à Gest’Hand, le logiciel qui centralise la gestion des licences pour les clubs, comités et ligues. L’accès est suspendu, une plainte est déposée, la CNIL et l’ANSSI sont saisies. Parmi les mesures annoncées pour la réouverture : la double authentification, qui deviendra obligatoire pour l’ensemble des utilisateurs.

C’est la deuxième intrusion sur le même outil en huit mois — un premier accès non autorisé avait été communiqué en décembre 2025. À l’époque déjà, les accès en cause avaient été neutralisés et les mots de passe réinitialisés.

Rien ici ne mérite le procès en négligence. La séquence est simplement celle que nous observons dans la quasi-totalité des organisations : la MFA est décidée après, jamais avant. Ce qui mérite d’être examiné, c’est pourquoi.

Trois objections, trois réponses

« Les prestataires, on ne gère pas leurs téléphones. » C’est le point d’entrée le plus fréquent, et le plus simple à corriger sur le papier. Un prestataire qui accède à votre système d’information utilise un compte que vous créez, dans votre annuaire, avec votre politique. Vous n’avez pas besoin de gérer son téléphone : vous exigez qu’il enrôle un facteur, comme n’importe quel utilisateur.

Ce qui bloque réellement, ce n’est pas la technique, c’est le contrat. Beaucoup de contrats d’infogérance et de maintenance applicative sont muets sur les modalités d’authentification, ou pire, prévoient un compte partagé pour l’équipe support du prestataire. Un compte partagé rend la MFA inopérante et l’imputabilité impossible : après incident, personne ne peut dire qui s’est connecté.

L’incident de la FFHandball est instructif sur ce point : c’est le prestataire en charge de Gest’Hand qui est intervenu avec la fédération, sur les deux occurrences. La frontière entre ce que vous contrôlez et ce que contrôle votre fournisseur est exactement l’endroit où se situe le risque.

« Les comptes de service, c’est techniquement impossible. » Objection valide. Un script qui s’authentifie toutes les nuits ne peut pas saisir un code à six chiffres. La bonne réponse n’est pas de forcer la MFA, c’est de retirer à ces comptes ce qui les rend intéressants.

Concrètement : pas d’ouverture de session interactive, pas d’accès à l’interface web d’administration, restriction par adresse IP source, secret long stocké dans un coffre et non dans un fichier de configuration, rotation planifiée, et journalisation des usages avec alerte sur tout comportement hors norme — connexion depuis une adresse inhabituelle, à une heure inhabituelle. Un compte de service correctement cloisonné vaut mieux qu’un compte nominatif avec MFA mais administrateur du domaine.

« Il y a des gens sans smartphone. » Réelle, et souvent traitée par une exemption qui devient permanente. Les réponses existent : clé matérielle FIDO2, application sur poste, codes à usage unique imprimés pour les cas résiduels. Le coût d’une clé est sans commune mesure avec celui d’une intrusion, et le nombre de personnes réellement concernées est presque toujours inférieur à ce qui est annoncé au lancement du projet.

Ce que la MFA ne couvre pas

Il faut être honnête sur les limites, parce qu’un déploiement présenté comme une solution complète produit un relâchement ailleurs.

La MFA ne protège pas contre le vol de session. Un attaquant qui récupère un cookie d’authentification valide n’a pas besoin de repasser par la connexion. C’est le mode opératoire dominant des kits de hameçonnage modernes, qui interceptent le jeton en temps réel. La parade porte sur la durée de vie des sessions, la liaison de la session à l’appareil, et la MFA résistante au hameçonnage — FIDO2, qui lie l’authentification au domaine et rend le relais inopérant.

Elle ne protège pas non plus contre l’abus de droits légitimes. Dans le cas de Gest’Hand, l’accès revendiqué reposait sur des identifiants compromis, puis sur le contournement des restrictions qui limitaient normalement la consultation au périmètre d’un seul club. L’authentification n’est qu’une moitié du sujet : l’autre est le contrôle d’accès applicatif, c’est-à-dire ce qu’un compte authentifié a le droit de voir. Un compte de club qui peut interroger la base entière est une faille de conception que la MFA ne referme pas.

Enfin, elle ne dispense pas de la surveillance. Un facteur supplémentaire élève le coût de l’attaque ; il ne la rend pas visible. La détection reste un chantier distinct.

L’argument qui fait décider

Nous constatons qu’aucune démonstration technique ne déclenche l’arbitrage. Deux éléments le font.

Le premier est réglementaire. L’article 32 du RGPD impose des mesures adaptées au risque, et l’absence de MFA sur un accès distant à une base contenant des données d’identité est difficile à défendre devant une autorité après incident. Le référentiel de l’ANSSI publié en mars la range parmi les objectifs de sécurité attendus. Dans le cas présent, où figurent des pièces d’identité et des données de mineurs, l’examen sera d’autant plus attentif.

Le second est contractuel. Les questionnaires fournisseurs posent désormais la question directement, et une réponse négative se traduit par une exclusion ou une réserve. Le coût du non-déploiement devient visible en cycle de vente, ce qui est le seul endroit où il finit par être entendu.

Sources

• FFHandball — communiqué du 11 août 2026 relatif à l’accès non autorisé détecté le 10 août sur Gest’Hand ; communication de décembre 2025 sur un premier incident
• ANSSI — recommandations relatives à l’authentification multifacteur et aux mots de passe ; Référentiel Cyber France (ReCyF), mars 2026
• Règlement (UE) 2016/679 (RGPD), article 32