Empêcher l'énumération des comptes lors de l'inscription, la connexion et la réinitialisation

À quoi ressemble l'énumération de comptes dans la vraie vie

L'énumération de comptes se produit lorsqu'une personne peut savoir si un e‑mail, un nom d'utilisateur ou un numéro de téléphone est enregistré simplement en observant la façon dont votre appli répond. L'attaquant n'a pas besoin de se connecter. Il lui suffit d'essayer beaucoup de valeurs et de repérer des différences dans les messages, les codes d'état, le timing ou les effets secondaires.

Les pages d'inscription, de connexion et de réinitialisation sont des cibles fréquentes parce qu'elles sont publiques et qu'elles se comportent naturellement différemment quand un compte existe. Cela facilite les fuites d'indices par inadvertance.

Un exemple simple : un formulaire de réinitialisation de mot de passe affiche :

• « Nous vous avons envoyé un lien de réinitialisation » quand l'e‑mail existe
• « Aucun compte trouvé » quand il n'existe pas

Un attaquant peut charger une liste de 50 000 e‑mails et apprendre rapidement qui utilise votre produit. Cette liste peut être vendue, utilisée pour du harcèlement ou pour du phishing ciblé (« Je sais que vous avez un compte, cliquez ici »). Cela rend aussi le credential stuffing plus efficace car les attaquants se concentrent sur les e‑mails déjà confirmés.

L'énumération est aussi un problème de confidentialité. Même confirmer qu'une personne a un compte peut être sensible pour des produits liés à la santé, la finance, le travail ou l'éducation.

L'objectif est simple : faire en sorte que l'issue visible par l'utilisateur soit indiscernable que le compte existe ou non, tout en conservant une forte visibilité interne. Les utilisateurs doivent voir le même message, le même motif de code d'état et un temps de réponse similaire. En interne, vous enregistrez toujours la vérité dans les logs et les métriques.

Les signaux que les attaquants utilisent pour deviner si un compte existe

Les attaquants n'ont pas besoin de votre base de données. Ils n'ont besoin que de minuscules différences dans ce que votre appli renvoie quand quelqu'un tape un e‑mail ou un numéro de téléphone.

Les signaux les plus évidents se trouvent dans la réponse elle‑même : un 404 pour « utilisateur non trouvé » versus 200 pour « réinitialisation envoyée », ou du JSON comme error: \"no_such_user\". Même si le texte semble convivial, des codes d'état différents, des codes d'erreur ou des formes de réponse différentes facilitent l'automatisation.

Le comportement de l'interface peut être tout aussi révélateur. Si l'application web dit « Aucun compte trouvé » à la connexion, mais que l'app mobile dit toujours « Vérifiez votre e‑mail », les attaquants utiliseront le plus simple. Le même problème apparaît quand les pages HTML diffèrent des API JSON : l'une peut fuir un indice dans le corps, un en‑tête ou une redirection.

Signaux courants mesurés par les attaquants :

• Codes d'état et codes d'erreur (200 vs 404, USER_NOT_FOUND vs INVALID_PASSWORD)
• Texte des messages et états UI (bannières différentes, champs en surbrillance, boutons désactivés)
• Timing des réponses (échec rapide pour les utilisateurs inconnus, chemin plus lent pour les vrais utilisateurs)
• Incitations secondaires (CAPTCHA apparaissant seulement après un e‑mail « réel »)
• Effets hors bande (e‑mail/SMS envoyés seulement pour les comptes existants)

Les différences de timing importent plus que la plupart des équipes ne l'imaginent. Si une requête de réinitialisation renvoie en 40 ms pour un e‑mail manquant mais en 400 ms lorsqu'on génère un token, écrit en base et met en file un e‑mail, les attaquants peuvent utiliser cet écart comme un signal fiable.

Surveillez aussi les fuites accidentelles via les outils. Si des détails d'erreur internes ou des codes de raison sont renvoyés au client (directement ou via des logs clients verbeux), les attaquants peuvent apprendre « l'utilisateur existe » sans que votre UI ne le dise jamais.

Choisir un modèle de réponse sûr par endpoint

La façon la plus rapide de réduire le risque d'énumération est de décider dès le départ ce que l'utilisateur verra dans chaque flux, puis de vous y tenir : même message, même écran et même étape suivante.

Traitez chaque flux séparément (connexion, inscription, réinitialisation), mais soyez cohérent au sein du flux. Utilisez un langage neutre et non engageant. Évitez les formulations qui confirment l'existence comme « introuvable », « aucun compte », « déjà enregistré », ou « l'utilisateur n'existe pas ».

Modèles de réponse sûrs qui fonctionnent généralement :

• Connexion : utilisez un échec générique comme « Impossible de vous connecter. Vérifiez vos informations et réessayez. » Gardez les mêmes options d'aide disponibles à chaque fois.
• Inscription : affichez quelque chose comme « Si vous pouvez recevoir des e‑mails à cette adresse, vous recevrez bientôt les étapes suivantes. » Ne changez pas l'UI selon que l'adresse est déjà utilisée.
• Réinitialisation de mot de passe : affichez toujours « Si un compte correspond à cet e‑mail, nous avons envoyé les instructions de réinitialisation. » Redirigez toujours vers le même écran de confirmation.

Le texte n'est qu'une partie. Les attaquants observent le comportement complet. Alignez ces éléments sur tous les résultats :

• Même pattern de codes d'état HTTP
• Plage de temps de réponse similaire (évitez les chemins d'échec trop rapides)
• Même page, mêmes boutons et mêmes appels à l'action
• Même nombre d'étapes avant confirmation

Une approche pratique pour la réinitialisation : affichez immédiatement l'écran de confirmation et lancez le travail en arrière‑plan. En interne, journalisez si un e‑mail a été envoyé, rebondi, supprimé ou bloqué, mais ne reflétez jamais cela dans la réponse publique.

Étapes : rendre les réponses indiscernables

Vous avez besoin d'un contrat clair : un endpoint doit sembler identique pour un appelant externe, que le compte existe ou non. Cela signifie faire correspondre le message visible, le code HTTP et la « sensation » de la réponse.

Commencez par écrire ce que vous avez aujourd'hui, puis resserrez avec de petits changements testables :

• Faites l'inventaire de chaque point d'entrée d'auth : inscription, connexion, réinitialisation de mot de passe, vérification d'e‑mail, « renvoyer le code », plus chaque client qui les appelle (web, mobile, API publique).
• Construisez une matrice de réponses pour chaque endpoint (succès, mauvais mot de passe, e‑mail inconnu, compte verrouillé, MFA requis). Marquez quels champs, codes d'état et branches UI diffèrent aujourd'hui.
• Standardisez ce que le client peut voir : choisissez une stratégie de code d'état par endpoint et un corps de réponse qui ne confirme jamais l'existence d'un compte.
• Normalisez le timing : si un chemin sort tôt, rapprochez‑le du chemin le plus lent. Vous pouvez ajouter un petit jitter, ou effectuer le même type de travail sur les deux chemins.
• Mettez à jour le comportement UI pour respecter le contrat : ne montrez pas « e‑mail introuvable ». Affichez toujours la même étape suivante.

Puis verrouillez‑le avec des tests pour éviter les régressions lorsque le code change.

Tests pour maintenir des réponses indiscernables

Les tests automatisés doivent comparer les sorties entre des cas qui fuitaient des signaux :

• Assurer le même code d'état et la même forme de réponse pour « e‑mail connu » vs « e‑mail inconnu ».
• Assurer que les messages d'erreur sont identiques (ou également vagues) entre les cas d'échec.
• Mesurer le timing pour les deux chemins et échouer le test si l'écart dépasse un seuil réduit.
• Ajouter un test d'intégration qui simule une requête complète de réinitialisation et confirme que l'UI ne se ramifie pas sur « compte existant ».

Inscription, connexion et réinitialisation : modèles de messages pratiques

Pour empêcher l'énumération, vos réponses publiques doivent ressembler aux mêmes que le compte existe ou pas. L'astuce : être ennuyeux à l'extérieur tout en restant précis à l'intérieur (logs, métriques, outils de support).

Modèles de réponse endpoint (ce que voit le client)

Gardez les codes d'état et la forme du message cohérents. Si vous renvoyez du JSON, retournez toujours les mêmes champs.

• Login (any failure): 401 with { \"error\": \"Invalid email or password.\" }
• Signup (accept request, even if email is in use): 200 with { \"message\": \"If you can sign up, you’ll receive an email with next steps.\" }
• Password reset (always): 200 with { \"message\": \"If an account exists for that email, we sent reset instructions.\" }

Sur la connexion, il est normal de renvoyer 401 pour une authentification échouée. L'important est que tous les échecs de connexion se ressemblent (e‑mail inconnu vs mauvais mot de passe), y compris la forme de la réponse et le timing.

Modèles d'e‑mail/SMS (ce que l'utilisateur reçoit)

Le contenu des messages peut lui aussi fuité l'existence. Évitez les e‑mails « Aucun compte trouvé ». Privilégiez le silence ou des notes génériques.

Exemples qui fonctionnent :

• Vérification d'inscription : « Confirmez votre e‑mail pour continuer. Si vous n'avez pas demandé ceci, ignorez ce message. »
• E‑mail de réinitialisation : « Nous avons reçu une demande de réinitialisation de mot de passe. Si vous n'avez pas demandé cela, ignorez ce message. »
• SMS de réinitialisation : « Votre code de réinitialisation est 123456. Si vous n'avez pas demandé cela, ignorez ce message. »

Pour les comptes inexistants, le modèle le plus sûr est souvent silencieux : afficher le même message à l'écran, mais ne rien envoyer.

Conserver l'analytics et les outils de support sans fuir d'infos

Des réponses uniformes ne signifient pas que vous devez naviguer à l'aveugle. Vous pouvez capturer exactement ce qui s'est passé, vous gardez juste le détail côté serveur.

Un schéma simple : retournez le même message côté utilisateur, mais enregistrez un code raison interne stable pour chaque requête. Ces codes ne doivent jamais apparaître dans les réponses API, le texte UI ou les logs côté client.

Exemples de codes raison internes :

• login_failed_no_user
• login_failed_wrong_password
• login_failed_mfa_required
• reset_requested_no_user
• reset_sent

Associez chaque requête d'auth à un ID de corrélation généré côté serveur. Utilisez‑le dans les logs serveur et les événements d'audit pour tracer une requête entre votre service d'auth, le fournisseur d'e‑mail et la base de données sans rien exposer à l'utilisateur. Si vous affichez un ID de requête à l'utilisateur pour le support, gardez‑le générique et assurez‑vous qu'il ne révèle pas le statut du compte.

Les équipes support ont toujours besoin d'aider de vraies personnes. Gardez les outils de recherche derrière une authentification du personnel et limitez par défaut les informations affichées. « Compte trouvé » est acceptable dans la console interne ; cela ne doit jamais être quelque chose qu'un appelant public puisse déduire.

Soyez strict avec les PII. Journalisez le moins possible tout en restant utile :

• Hachez ou tokenisez les e‑mails dans les logs quand c'est possible
• Stockez les e‑mails complets uniquement dans des systèmes qui ont déjà une politique pour eux
• Gardez des durées de rétention courtes sauf si la conformité exige plus

Ajouter des garde‑fous : throttling, détection et contrôles d'abus

Les messages uniformes sont la base, mais pas toute la défense. Il vous faut aussi des garde‑fous qui ralentissent les attaquants et vous aident à repérer les motifs tôt.

Limitation et délais progressifs

Commencez par des limites de taux qui rendent l'automatisation coûteuse sans nuire aux utilisateurs normaux. Appliquez les limites par IP et empreinte d'appareil, et ajoutez un contrôle réfléchi sur l'identifiant soumis (e‑mail/téléphone) sans en faire un nouveau signal. Une approche commune consiste à garder des compteurs séparés et à appliquer le résultat le plus strict.

Après plusieurs tentatives, ajoutez des délais croissants. Maintenez le même comportement de délai que le compte existe ou non. Si vous appliquez un verrouillage, ne dites pas « compte verrouillé » dans le message utilisateur. Traitez le verrouillage comme un état interne.

Une configuration pratique :

• Limite par IP (fenêtre courte) pour arrêter les rafales
• Limite par appareil pour attraper les IP partagées (cafés, bureaux)
• Limite par identifiant pour ralentir le guessing ciblé
• Délai progressif après N échecs, appliqué uniformément
• Verrouillage souple avec cooldown, plus alerting interne

Le CAPTCHA peut aider, mais ne l'affichez pas seulement quand un e‑mail existe. Déclenchez‑le selon des signaux de risque (volume, vélocité, indices d'automatisation suspecte) et gardez le texte côté utilisateur cohérent.

Détection et monitoring des abus

L'énumération a des patterns que vous pouvez surveiller. Un bot peut essayer des centaines d'e‑mails uniques depuis une même IP, ou quelques e‑mails depuis de nombreuses IP.

Surveillez et alertez sur :

• Volume élevé de requêtes sur login/reset/signup
• Beaucoup d'identifiants uniques par IP ou appareil
• Tentatives répétées avec faible taux de succès
• Pics à des heures étranges ou depuis de nouvelles régions
• Schémas entre endpoints (reset puis login avec les mêmes identifiants)

Erreurs courantes qui réintroduisent de l'énumération

Beaucoup d'équipes corrigent le texte évident, puis fuguent l'existence via des canaux secondaires. Les attaquants testent le flux complet, pas seulement la phrase à l'écran.

Des codes d'état HTTP différents sont un signal instantané. Si un e‑mail connu renvoie 200 mais qu'un e‑mail inconnu renvoie 404 (ou 422), les bots le verront immédiatement.

Le timing est le suivant témoin. Un chemin touche la base, envoie un e‑mail ou fait du hashing de mot de passe tandis que l'autre sort tôt. Vous n'avez pas besoin d'un temps constant parfait, mais évitez des écarts cohérents fast‑fail vs slow‑path.

Le contenu des e‑mails peut aussi fuité. Les e‑mails de réinitialisation qui incluent le nom du plan, la dernière connexion ou un salut personnalisé confirment que le compte est réel. Gardez-les génériques jusqu'à ce que l'utilisateur prouve le contrôle de la boîte en suivant le token.

La logique UI fuit souvent. Un prompt « Créer un compte » qui n'apparaît que quand l'e‑mail est inconnu est un indice. La validation inline comme « e‑mail déjà utilisé » est utile pour les vrais utilisateurs, mais c'est aussi un annuaire pour les attaquants.

Checklist rapide :

• Retournez la même stratégie de code d'état et le même JSON structuré pour les deux résultats
• Gardez le temps de réponse dans la même zone pour les deux chemins
• Évitez les erreurs au niveau des champs qui impliquent l'existence
• Ne changez pas les options UI selon que l'e‑mail existe
• Gardez les e‑mails de réinitialisation génériques jusqu'à vérification de contrôle

Vérifications rapides avant mise en production

Avant de déployer, testez comme un attaquant. Un appelant externe ne doit pas pouvoir dire si un compte existe, tandis que votre équipe obtient toujours la vérité dans la télémétrie interne.

Une checklist rapide :

• Pour la connexion et la réinitialisation, confirmez que vous renvoyez le même pattern de codes d'état pour comptes existants et non‑existants.
• Comparez les corps de réponse cote à cote. Ils doivent avoir les mêmes champs, types de données et longueur à peu près similaire.
• Lisez les textes d'e‑mail et SMS comme un étranger. Les messages ne doivent jamais confirmer qu'une adresse ou un numéro est enregistré.
• Vérifiez que les logs internes enregistrent le résultat réel (utilisateur trouvé vs non trouvé, token créé vs ignoré) avec un ID de requête que votre support peut rechercher.
• Confirmez que les outils support montrent les résultats seulement après authentification du personnel, pas dans des réponses publiques.

Faites ensuite un test de timing. Choisissez un endpoint (la réinitialisation est un bon départ) et testez 20–30 requêtes avec un e‑mail existant et un e‑mail qui n'existe pas. Vous recherchez un écart clair et reproductible. Si vous en voyez un, bourrez légèrement le chemin rapide ou déplacez le travail coûteux en tâche asynchrone.

Exemple : corriger un flux de réinitialisation qui fuit

Une petite équipe SaaS commence à recevoir des rapports clients : « Quelqu'un essaie sans cesse de réinitialiser mon mot de passe. » Leurs logs montrent beaucoup de requêtes de réinitialisation pour des adresses qui ressemblent à une liste client. Le pattern est classique : quelqu'un fait des sondages pour savoir quels e‑mails existent.

L'ancien endpoint de réinitialisation avait deux issues faciles à repérer :

• Si l'e‑mail n'existait pas : « E‑mail introuvable. Essayez de vous inscrire. »
• Si l'e‑mail existait : « Vérifiez votre boîte pour un lien de réinitialisation. »

Cette différence suffit pour confirmer des comptes valides à grande échelle. Même si l'UI semble similaire, de petits changements de code d'état, de corps de réponse ou de timing peuvent encore fuir.

La correction consiste à rendre la réponse publique identique à chaque fois, puis à enregistrer le résultat réel en interne avec des codes raison.

Comportement public (nouveau) : même message UI et même HTTP status pour toutes les requêtes, par exemple : « Si un compte correspond à cet e‑mail, nous avons envoyé les instructions. »

Comportement interne (nouveau) : écrire un événement structuré pour que l'analytics, la sécurité et le support puissent agir :

{
  "event": "password_reset_requested",
  "email_hash": "sha256(...)" ,
  "result": "SENT" ,
  "reason_code": "OK",
  "ip": "203.0.113.10",
  "user_agent": "...",
  "request_id": "..."
}

Si l'e‑mail n'existe pas, gardez la même réponse publique mais logguez result: "NOOP" avec reason_code: "ACCOUNT_NOT_FOUND". Si vous bloquez pour contrôle d'abus, logguez reason_code: "RATE_LIMIT".

Le support peut toujours aider sans confirmer quoi que ce soit publiquement. Si quelqu'un dit « Je n'ai pas reçu l'e‑mail », le support peut rechercher le dernier événement de réinitialisation par hash d'e‑mail ou ID de requête. Si les événements montrent des NOOP répétés, l'utilisateur a probablement mal saisi l'adresse. Si les événements montrent SENT sans livraison, vous pouvez vérifier les rebonds chez le fournisseur d'e‑mail sans changer ce que le formulaire révèle.

Pour valider la correction, faites un test avant/après : essayez la réinitialisation avec un e‑mail connu et un e‑mail aléatoire, puis comparez codes d'état, corps de réponse et timing. Ils doivent être indiscernables de l'extérieur, tandis que vos logs montrent toujours les vrais résultats.

Prochaines étapes : déploiement sûr et seconde relecture

Standardisez un endpoint à la fois. La réinitialisation est souvent la plus critique car elle est facile à sonder et fuit fréquemment des différences évidentes. Une fois la réinitialisation cohérente, passez à la connexion, puis à l'inscription.

Avant de déployer, gardez un plan de test simple qui couvre votre UI web et tous les clients API (apps mobiles, intégrations, outils CLI). Soyez strict sur ce que « même réponse » signifie sur tous ces clients.

• Essayez des e‑mails/nom d'utilisateur valides et invalides et comparez codes d'état, forme du corps et timing
• Testez comptes verrouillés, e‑mails non vérifiés et utilisateurs avec MFA
• Confirmez que l'UI guide toujours les vrais utilisateurs sans dire « ce compte existe »
• Vérifiez que les logs et métriques capturent toujours le résultat réel en interne
• Contrôlez la localisation, car les traductions peuvent réintroduire des messages différents

Si vous travaillez avec du code d'auth généré par IA, assumez qu'il peut exister des fuites cachées (champs JSON supplémentaires, retours précoces, gestion d'erreur différente entre clients). FixMyMess (fixmymess.ai) se concentre sur le diagnostic et la réparation de ces problèmes de production, y compris le resserrement des réponses d'auth tout en conservant une télémétrie utile pour le support et la sécurité.