Aller au contenu

Pourquoi limiter les tentatives de connexion

Kirexo bloque temporairement la connexion après plusieurs échecs successifs. Cette page explique le raisonnement derrière ce comportement : contre quoi il protège, pourquoi l'espace d'administration est plus strict, et le compromis qu'il représente entre sécurité et confort d'usage. Pour les valeurs exactes et leur emplacement de configuration, voir la Référence de la configuration de sécurité.

Le problème : deviner un mot de passe coûte presque rien

Sans garde-fou, un formulaire de connexion accepte autant de tentatives qu'on lui en envoie. Un attaquant peut donc essayer des milliers de mots de passe à la seconde, automatiquement. Deux attaques classiques en découlent :

  • Brute-force — on cible un compte connu et on déroule une liste de mots de passe (dictionnaire, variations courantes) jusqu'à tomber juste.
  • Credential stuffing — on rejoue en masse des couples email / mot de passe volés ailleurs (fuites de données d'autres sites), en pariant sur la réutilisation de mots de passe d'un site à l'autre.

Ces deux attaques reposent sur le volume : leur efficacité dépend du nombre d'essais qu'on peut enchaîner. Tout ce qui ralentit le rythme des tentatives réduit mécaniquement leur taux de réussite.

La réponse : ralentir, pas interdire

Kirexo s'appuie sur le login throttling natif de Symfony. Après un certain nombre de tentatives échouées sur une même cible, l'accès est temporairement bloqué pendant une fenêtre glissante. Un essai de plus pendant le blocage est rejeté sans même vérifier le mot de passe.

Deux principes guident ce choix :

  • Indexation par IP + identifiant. Le compteur n'est pas global : il porte sur le couple (adresse IP, email saisi). Bloquer un attaquant qui martèle un compte ne pénalise donc pas les autres utilisateurs légitimes connectés depuis ailleurs. À l'inverse, un même attaquant qui change de compte cible voit chaque cible protégée indépendamment.
  • Un succès remet le compteur à zéro. Dès qu'une connexion réussit, le compteur d'échecs de cette cible repart de zéro. Une personne qui se trompe deux fois puis réussit ne traîne aucune pénalité.

Le but n'est pas d'interdire définitivement l'accès — ce serait une arme de déni de service contre l'utilisateur légitime — mais de rendre une attaque par volume trop lente pour être rentable. Quelques essais autorisés par fenêtre de quinze minutes suffisent à casser net un script qui en tenterait des milliers.

Pourquoi l'admin est plus strict

L'espace utilisateur tolère 5 tentatives par fenêtre de 15 minutes ; l'espace d'administration n'en tolère que 3. Ce n'est pas arbitraire :

  • L'enjeu n'est pas le même. Un compte utilisateur compromis expose les articles et les réglages de diffusion d'une personne. Un compte administrateur compromis expose la gestion de tous les comptes de la plateforme. Le coût d'une intrusion réussie est bien plus élevé côté admin, donc on accepte d'y être plus sévère.
  • La population est plus petite et plus avertie. Les administrateur·rices sont peu nombreux·ses et connaissent leur mot de passe. Le risque qu'une limite basse gêne un usage légitime est faible, alors qu'il protège une cible à très forte valeur.
  • Cohérence avec le reste de la défense admin. L'espace d'administration se rend déjà invisible aux non-admins (404 plutôt que 403, cf. Architecture des firewalls). Une limite de tentatives plus basse prolonge cette posture « l'admin se défend davantage » de façon homogène.

Le compromis UX / sécurité

Toute limite de tentatives est un curseur entre deux risques opposés :

  • Trop permissif → l'attaque par volume redevient praticable.
  • Trop strict → un·e utilisateur·rice légitime qui se trompe quelques fois (faute de frappe, hésitation entre deux mots de passe) se retrouve verrouillé·e, ce qui est frustrant et génère du support.

Kirexo place le curseur de façon à absorber les erreurs humaines normales sans ouvrir la porte aux scripts :

  • 5 essais / 15 min côté utilisateur laisse une marge confortable pour se tromper puis se rappeler du bon mot de passe, tout en plafonnant à 20 essais par heure et par cible — dérisoire pour une attaque automatisée.
  • 3 essais / 15 min côté admin resserre la marge là où l'enjeu le justifie.
  • La fenêtre glissante (et non un blocage fixe qui repartirait à zéro d'un coup) évite qu'un attaquant ne synchronise ses rafales sur la remise à zéro du compteur.
  • Le reset du compteur sur succès garantit qu'une personne légitime ne paie jamais ses erreurs passées une fois connectée.

Surtout, le throttling se combine avec la couche anti-énumération du formulaire (voir Se connecter à Kirexo) : un attaquant ne sait déjà pas quels emails correspondent à des comptes, et même quand il en devine un, il ne peut le marteler que quelques fois par quart d'heure. Les deux mécanismes se renforcent.

Ce que la limitation ne fait pas

Le throttling ralentit les attaques en ligne, mais il ne remplace pas :

  • Un mot de passe robuste — il rend le brute-force lent, pas impossible sur un mot de passe trivial.
  • La réinitialisation de mot de passe en cas de compromission avérée (cf. Réinitialiser son mot de passe), qui invalide aussi les sessions « se souvenir de moi ».

C'est une brique de défense en profondeur parmi d'autres, pas un rempart unique.

Voir aussi