Ne pas envoyer de message à l'utilisateur final pour lui dire pourquoi la connexion a échoué. Vous donnez à un attaquant potentiel des informations critiques pour l'aider à attaquer votre application.

D'un autre côté, ne pas dire à un utilisateur pourquoi sa connexion a échoué est un désastre potentiel en termes d'utilisation.

Si vous ne clarifiez pas si l'adresse IP de l'utilisateur a été bannie ou si l'utilisateur a plutôt utilisé un mot de passe incorrect, il pourrait paniquer car il leur semble que quelqu'un a accédé à son compte et a changé le mot de passe pour le verrouiller. Si ma connexion avec un mot de passe prérempli échoue, la première chose à laquelle je pense est une effraction plutôt qu'un blocage IP.

De plus, un mécanisme de blocage IP naïf pourrait être inefficace et introduire des problèmes. Il est potentiellement trivial de contourner pour un attaquant disposant de ressources suffisantes et quelqu'un qui partage une adresse IP avec d'autres utilisateurs pourrait abuser de l'interdiction IP pour en verrouiller d'autres. Au lieu de cela, un CAPTCHA après n tentatives infructueuses par IP peut être une solution plus douce et plus appropriée pour votre application.

Voir aussi:

• Est-ce une bonne pratique de interdire une adresse IP si trop de tentatives de connexion sont effectuées à partir de celle-ci?
• Pourquoi les gens utilisent-ils des interdictions d'adresses IP alors que les adresses IP changent souvent?

Il y a un avantage de sécurité à fournir des messages génériques qui n'ont pas été mentionnés.

Alice tente de forcer brutalement un compte sur le serveur de Bob. Pour les premières tentatives, Alice récupère le message "Echec de la tentative de connexion". Lors de la prochaine tentative, elle obtient "Trop de tentatives de connexion à partir de cette adresse IP". Elle est maintenant consciente que (a) toutes les informations d'identification qu'elle a essayées jusqu'à présent n'étaient pas valides, et (b) elle doit faire quelque chose de différent avant de faire d'autres tentatives.

Mais qu'en est-il si Bob ne change pas le message? Alice continuera avec la force brute et continuera à obtenir la "tentative de connexion échouée" générique à chaque tentative même si les informations d'identification sont correctes . Si elle essaye les informations d'identification correctes, Bob rejettera la tentative car la limite IP a été dépassée, mais Alice ne saura pas que c'est la raison et devra la traiter comme une tentative incorrecte (à moins qu'elle n'en ait manière de savoir ce qui dépasse le cadre de cette question). Sa seule option est de poursuivre la recherche, sans savoir si elle a déjà localisé et dépassé les informations d'identification correctes.

Notez que cet avantage est la sécurité par l'obscurité car il se fie au fait qu'Alice ne connaît pas la politique de blocage IP de Bob. Selon la configuration, ces informations peuvent être faciles à obtenir. Par exemple, si Alice a accès à un autre compte sur le système (facile si elle accepte l'enregistrement d'un compte public), elle peut utiliser des essais et des erreurs pour voir si une tentative correcte est finalement rejetée après trop de tentatives incorrectes.

D'autres réponses ont expliqué le compromis sécurité / convivialité, je ne vais donc pas me donner la peine de le répéter.

Oui, techniquement, vous renvoyez des informations qui pourraient être utilisées par un attaquant pour affiner un botnet de force brute. De plus, je ne suis pas sûr de l'utilité du message d'erreur «À plusieurs tentatives de connexion à partir de cette adresse IP» pour un utilisateur standard. Il convient également de noter que tout attaquant chevronné commencera à remarquer soit un type de réponse changeant, soit une différence de temps, et comprendra probablement ce qui se passe de toute façon.

Vous pouvez envisager d'utiliser un service tel que CloudFlare. Ils ont une API scriptable qui peut insérer dynamiquement une page interstitielle ou mettre à jour une règle WAF dans certains scénarios. Troy Hunt propose un bon didacticiel dans lequel il effectue cette opération pour Windows Azure à l'aide d'Azure Functions.

Dans ce cas, la sécurité et la convivialité sont des objectifs contraires. Si la mise en œuvre la plus sécurisée n'offrirait aucun retour d'information, elle serait également la moins conviviale. Vous devez décider du degré de vulnérabilité de votre système à la brutalisation des connexions, des autres mesures d'atténuation en place et de l'efficacité de l'atténuation spécifique lorsqu'elle est évaluée pour ne pas gêner l'utilisateur.

Par exemple, si je concevais une connexion pour un appareil grand public Je le rendrais aussi convivial que possible en ayant des commentaires détaillés et en introduisant des atténuations supplémentaires pour compenser. Si je concevais la connexion HSM, je n'offrirais aucun commentaire et des délais d'attente onéreux à l'échelle de l'appareil.

Tout dépend de ce que vous construisez. S'il s'agit d'un blog ou de tout autre site sophistiqué où il n'est pas vraiment important de rejeter les tentatives légitimes, et où vous ne faites pas vraiment confiance à la robustesse de l'application, vous devez vraiment le protéger de tout ce qui pourrait être une attaque et ne jamais dire pourquoi vous refusez une connexion.

Si vous construisez une application professionnelle et que vous attendez des accès professionnels, ne limitez pas les accès à partir d'une seule IP si votre application est suffisamment robuste. Si vous le faites, assurez-vous d'informer l'utilisateur de la raison et de mettre en place une hot line raisonnablement réactive (au plus 1 jour ouvrable pour lire et comprendre un message, et pour initier une action corrective si nécessaire ). Parce qu'il est courant pour les grandes organisations de configurer un seul proxy sortant pour tous leurs accès HTTP et HTTPS. Vous pouvez avoir des milliers d'employés dans différents endroits d'un pays, tous utilisant apparemment la même adresse IP. Une liste blanche autorisant des connexions illimitées à partir de proxys connus suffit, mais vous devez être prêt à la changer rapidement si l'un de vos clients fait évoluer son réseau et change son adresse proxy.