Limiter le nombre d'essais de connexion

[Monadologie]

Bonsoir,

Il est actuellement possible de réaliser, a priori, une infinité de requêtes pour tenter de se connecter à son compte via cette page-ci. Je crois important de limiter le nombre de requêtes par session, par IP, ou bien encore en affichant un CAPTCHA après x requêtes échouées.

N'hésitez pas à transmettre vos commentaires, Merci.

[Monadologie]

Qu'en pensez-vous ? Serait-il plus important de limiter le nombre de requêtes par session, par IP, ou bien encore en affichant un CAPTCHA après x requêtes échouées ?

[WinXaito]

Pour moi c'est le captcha qui sera le plus efficace, à voir... mais pour avoir les X requêtes avant le captcha, il faut le faire probablement par IP.

[Monadologie]

C'est ce que je pensais aussi.

[vhf]

mais pour avoir les X requêtes avant le captcha, il faut le faire probablement par IP.

Pourquoi pas plutôt par username ?

[Monadologie]

Pourquoi pas plutôt par username ?

Cela pourrait être une bonne idée ; plus simple à mettre en place aussi.

[WinXaito]

En effet je n'y avais pas penser, et ça évite les attaques avec modification d'IP.

[Monadologie]

On pourrait raisonner de la manière suivante : Une fois qu'une erreur d'authentification se produit, si l'utilisateur recherché existe on rajoute 1 dans la colonne « failed_attempts ». Parallèlement, on vérifie à chaque requête si l'utilisateur (s'il existe, dans le cas contraire on return) n'a pas un « failed_attempts » >= 10 (par exemple). Si oui on rajoute un CAPTCHA dans la vue, sinon on laisse tomber. Toutefois, il faudrait vérifier en aval si le CAPTCHA a bien été rempli, et donc le cas où il ne doit pas y avoir de CAPTCHA, ne rien faire. Qu'en pensez-vous ?

[gllmc]

Il y a un truc qui me dérange : quand l'utilisateur clique sur le lien « Connexion », on ne sait pas sur quel compte il va se connecter. Du coup, s'il tente de se connecter avec un compte concerné par une « attaque », il va falloir refuser la connexion en renvoyant le formulaire avec le captcha, ce qui est un peu lourd.

Deuxième point : quand se termine une « attaque » ? Je pensais plutôt à un truc comme vérifier qu'il n'y a pas eu plus de 3 échecs dans les 15 dernières minutes (je donne des valeurs au pif, à voir si c'est pertinent). À voir ensuite si on purge la table, et comment.

[Monadologie]

Tout à fait ! J'ai également été intrigué par cela... Dès lors, il serait plus simple de vérifier l'IP non ?

[vhf]

Si on a un emmerdeur, ce sera une attaque ciblée, contre un voire quelques comptes non ? Les IPs c'est très bon marché. A part si vous venez avec un threat model plus convaincant que le mien, le check par IP j'achète pas. :)

[Monadologie]

J'ai une meilleure idée xD On laisse le CAPTCHA pour toutes les connexions, comme ça plus de problème de sécurité !

[vhf]

Si c'est blague, OK. Sinon, pas question. Accessibilité passe largement devant, dans une situation où on n'a pas de menace crédible.

[Monadologie]

Oui, c'est une blague.

[gllmc]

Du coup, je pense que malgré cet inconvénient, il faut rester sur le compte. Il faudrait d'afficher un message après une tentative de connexion de type : « Plusieurs tentatives de connexion échouées ont eu lieu sur votre compte. Afin d'en assurer la sécurité, veuillez remplir le captcha ci-dessous ».

[Monadologie]

Yep, on reste sur ça du coup. Tu prends, ou je prends ?

[gllmc]

Si tu t'en sens capable, n'hésite pas. Tu veux que je t'assigne ? Sinon, j'ai bien une idée de comment faire mais il n'y a rien de très prioritaire.

[Monadologie]

Pas pour le moment, merci... Je vais tester deux trois petits truc, si ça tiens pourquoi pas :) Pendant ce temps, tu peux y aller 👍