# language: fr @api @authentication @security @mvp Fonctionnalité: Limitation des tentatives de connexion En tant que système de sécurité Je veux limiter les tentatives de connexion échouées Afin de protéger les comptes utilisateurs contre les attaques par force brute Contexte: Étant donné que le système est configuré avec les limites suivantes: | Paramètre | Valeur | | Tentatives max avant blocage | 5 | | Durée de blocage temporaire | 15 min | | Tentatives max avant blocage 24h | 10 | | Durée de blocage prolongé | 24h | | Fenêtre de temps pour reset | 30 min | Scénario: Connexion réussie réinitialise le compteur de tentatives Étant donné un utilisateur "alice@roadwave.fr" avec 3 tentatives échouées Quand l'utilisateur se connecte avec les bons identifiants Alors la connexion est réussie Et le compteur de tentatives échouées est réinitialisé à 0 Et un événement de sécurité "LOGIN_SUCCESS_AFTER_FAILURES" est enregistré Scénario: Blocage temporaire après 5 tentatives échouées Étant donné un utilisateur "bob@roadwave.fr" avec 4 tentatives échouées Quand l'utilisateur tente de se connecter avec un mauvais mot de passe Alors la connexion échoue avec le code d'erreur "ACCOUNT_TEMPORARILY_LOCKED" Et le message est "Votre compte est temporairement verrouillé pour 15 minutes suite à de multiples tentatives échouées" Et un email de notification de sécurité est envoyé à "bob@roadwave.fr" Et un événement de sécurité "ACCOUNT_LOCKED_TEMP" est enregistré Et la métrique "security.account_locks.temporary" est incrémentée Scénario: Tentative de connexion pendant le blocage temporaire Étant donné un utilisateur "charlie@roadwave.fr" bloqué temporairement Et il reste 10 minutes avant la fin du blocage Quand l'utilisateur tente de se connecter avec les bons identifiants Alors la connexion échoue avec le code d'erreur "ACCOUNT_TEMPORARILY_LOCKED" Et le message contient "Votre compte reste verrouillé pour 10 minutes" Et le temps de blocage restant est indiqué en minutes Et la tentative ne rallonge pas la durée du blocage Scénario: Connexion autorisée après expiration du blocage temporaire Étant donné un utilisateur "david@roadwave.fr" bloqué temporairement il y a 16 minutes Quand l'utilisateur tente de se connecter avec les bons identifiants Alors la connexion est réussie Et le compteur de tentatives échouées est réinitialisé à 0 Et le statut de blocage est levé Et un événement de sécurité "ACCOUNT_UNLOCKED_AUTO" est enregistré Scénario: Blocage prolongé après 10 tentatives échouées sur 24h Étant donné un utilisateur "eve@roadwave.fr" avec historique: | Tentatives échouées | Quand | | 5 | Il y a 2 heures | | Blocage 15min levé | Il y a 1h30 | | 4 | Il y a 30 minutes | Quand l'utilisateur tente une nouvelle connexion échouée Alors la connexion échoue avec le code d'erreur "ACCOUNT_LOCKED_24H" Et le message est "Votre compte est verrouillé pour 24 heures suite à de multiples tentatives suspectes" Et un email urgent de sécurité est envoyé avec un lien de déblocage sécurisé Et une notification SMS est envoyée (si configuré) Et un événement de sécurité "ACCOUNT_LOCKED_24H" est enregistré avec niveau "HIGH" Et la métrique "security.account_locks.prolonged" est incrémentée Scénario: Blocage différencié par adresse IP Étant donné un utilisateur "frank@roadwave.fr" avec 3 tentatives échouées depuis IP "1.2.3.4" Quand l'utilisateur se connecte avec succès depuis IP "5.6.7.8" Alors la connexion est réussie Et le compteur de tentatives échouées pour IP "1.2.3.4" reste à 3 Et le compteur de tentatives échouées pour IP "5.6.7.8" est à 0 Et un événement de sécurité "LOGIN_FROM_NEW_IP" est enregistré Scénario: Alerte de sécurité sur pattern suspect multi-IP Étant donné un utilisateur "grace@roadwave.fr" Quand 5 tentatives échouées sont détectées depuis 5 IP différentes en 10 minutes: | IP | Tentatives | Timestamp | | 1.2.3.4 | 2 | Il y a 10 min | | 5.6.7.8 | 1 | Il y a 8 min | | 9.10.11.12 | 1 | Il y a 5 min | | 13.14.15.16| 1 | Il y a 2 min | Alors le compte est immédiatement bloqué pour 24h Et un email d'alerte critique "POSSIBLE_CREDENTIAL_STUFFING_ATTACK" est envoyé Et l'équipe de sécurité est notifiée via webhook Et toutes les sessions actives sont révoquées Et la métrique "security.attacks.credential_stuffing.detected" est incrémentée Scénario: Déblocage manuel par l'utilisateur via email sécurisé Étant donné un utilisateur "henry@roadwave.fr" bloqué pour 24h Et il a reçu un email avec un lien de déblocage sécurisé à usage unique Quand l'utilisateur clique sur le lien dans les 2 heures suivant l'email Et confirme son identité via un code envoyé par SMS Alors le compte est débloqué immédiatement Et l'utilisateur est invité à changer son mot de passe Et un événement de sécurité "ACCOUNT_UNLOCKED_MANUAL" est enregistré Et la métrique "security.account_unlocks.user_initiated" est incrémentée Scénario: Réinitialisation automatique du compteur après période d'inactivité Étant donné un utilisateur "iris@roadwave.fr" avec 3 tentatives échouées Et aucune nouvelle tentative depuis 35 minutes Quand l'utilisateur tente de se connecter avec un mauvais mot de passe Alors le compteur de tentatives est réinitialisé à 1 Et le message d'erreur est standard sans mention de blocage imminent Et un événement de sécurité "ATTEMPT_COUNTER_RESET" est enregistré Scénario: Protection contre les attaques par timing Étant donné un utilisateur "jack@roadwave.fr" Quand l'utilisateur effectue 10 tentatives de connexion échouées Alors chaque réponse HTTP prend entre 800ms et 1200ms (temps constant) Et les messages d'erreur ne révèlent pas si l'email existe Et la métrique "security.timing_protection.applied" est incrémentée Et les logs n'exposent pas de patterns de timing exploitables Scénario: Escalade des notifications avec tentatives répétées Étant donné un utilisateur "kate@roadwave.fr" Premium Quand les événements suivants se produisent: | Événement | Notification | | 3 tentatives échouées | Aucune notification | | 5 tentatives (blocage) | Email standard | | 10 tentatives (24h) | Email + SMS + notification app| | Tentative pendant 24h | Email urgent + alerte support | Alors chaque niveau de notification est proportionnel à la gravité Et l'utilisateur peut configurer ses préférences de notification Et la métrique "security.notifications.escalated" est incrémentée Scénario: Whitelist d'IP pour utilisateurs de confiance Étant donné un utilisateur "luke@roadwave.fr" avec IP de confiance "1.2.3.4" Et la whitelist est configurée pour autoriser 10 tentatives au lieu de 5 Quand l'utilisateur effectue 7 tentatives échouées depuis "1.2.3.4" Alors le compte n'est pas bloqué Et un avertissement est affiché "3 tentatives restantes avant blocage" Et un événement de sécurité "TRUSTED_IP_EXTENDED_ATTEMPTS" est enregistré Scénario: Logs de sécurité détaillés pour audit Étant donné un utilisateur "mary@roadwave.fr" avec tentatives échouées Quand un audit de sécurité est effectué Alors les logs contiennent pour chaque tentative: | Champ | Exemple | | Timestamp | 2026-02-03T14:32:18.123Z | | User ID | uuid-123-456 | | Email | mary@roadwave.fr | | IP Address | 1.2.3.4 | | User Agent | Mozilla/5.0 (iPhone...) | | Failure Reason | INVALID_PASSWORD | | Attempts Count | 3 | | Geolocation | Paris, France | | Device Fingerprint| hash-abc-def | Et les logs sont conservés pendant 90 jours minimum Et les logs sont conformes RGPD (pas de mots de passe en clair) Scénario: Métriques de performance du système de limitation Étant donné que le système traite 1000 tentatives de connexion par minute Quand les métriques de performance sont collectées Alors les indicateurs suivants sont disponibles: | Métrique | Valeur cible | | Temps de vérification du compteur | < 50ms | | Latence ajoutée par le rate limiting | < 100ms | | Pourcentage de tentatives bloquées | < 2% | | Faux positifs (utilisateurs légitimes) | < 0.1% | | Temps de déblocage automatique | < 1s | Et les métriques sont exportées vers le système de monitoring Et des alertes sont déclenchées si les seuils sont dépassés Scénario: Compatibilité avec authentification multi-facteurs Étant donné un utilisateur "nathan@roadwave.fr" avec 2FA activé Et il a 4 tentatives échouées (mot de passe correct mais code 2FA incorrect) Quand l'utilisateur tente une 5ème connexion avec mot de passe correct et mauvais code 2FA Alors le compte est bloqué temporairement Et le message précise "Blocage suite à de multiples erreurs de code 2FA" Et le compteur 2FA est distinct du compteur de mot de passe Et un événement de sécurité "2FA_LOCK_TRIGGERED" est enregistré