# 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é
