Est-il utile d'avoir un captcha sur un écran de connexion?
J'ai introduit recaptcha dans l'écran de connexion d'un système.
Mon objectif était tout au sujet des choses de sécurité comme les attaques par dictionnaire/bots ou autre chose de ce type.
Les utilisateurs le détestent maintenant, certains ne l'ont même pas compris et j'ai dû le supprimer.
Quand je regarde autour de moi, je ne vois pas beaucoup de systèmes avec cela sur l'écran de connexion, la plupart du temps sur d'autres formulaires comme nous contacter ou parfois comme dans l'échange de pile lorsque vous souhaitez publier.
Je me suis demandé si c'était une bonne idée de l'avoir sur l'écran de connexion?
La façon dont j'ai vu certains grands systèmes le faire est d'exiger un captcha uniquement après des tentatives de connexion échouées séquentielles (c'est-à-dire: réinitialiser le nombre après une connexion valide). Si vous craignez le craquage automatisé, vous pouvez mettre le captcha à un nombre élevé d'échecs comme 20, 50, 100 tentatives infructueuses. Presque aucun utilisateur légitime ne verra le captcha, mais une attaque automatisée en sera frappée.
Vaut-il la peine d'ajouter cette complexité? La sécurité et l'UX sont des compromis. Vous devez trouver le bon compromis pour votre profil de risque.
Un captcha sur un écran de connexion n'a aucun sens. Je ne suis pas surpris que vos utilisateurs le détestent. Le but des champs captcha sur les formulaires est d'empêcher qu'ils ne soient soumis par des bots. Un bot ne devrait pas pouvoir se connecter via votre écran de connexion, car il ne devrait pas avoir d'informations d'identification valides. Si un bot peut deviner des informations d'identification valides, vous devez augmenter la force du mot de passe.
Les utilisateurs le détestent maintenant, certains ne l'ont même pas compris et j'ai dû le supprimer.
C'est là que vous devrez prendre la décision entre l'utilisabilité et la sécurité. Bien qu'il soit utile d'avoir un captcha sur vos pages de connexion, il est incroyablement peu convivial.
Mon meilleur conseil serait de consigner chaque tentative de connexion non valide dans une base de données et avant d'authentifier l'utilisateur, vérifiez si cette IP a essayé de se connecter X fois au cours de la dernière heure.
Vous pouvez également ajouter une forme de système de contrefaçon de demande intersite à chaque page de connexion. Cela signifie qu'à chaque tentative de connexion, un champ caché avec un jeton sera généré, ce qui signifie qu'un attaquant devra faire deux demandes pour essayer de se connecter.
Une autre façon d'attaquer cela pourrait être d'installer un "pot de miel". Il s'agit d'un champ de saisie ordinaire qui est inclus dans le HTML avec les champs de connexion (nom d'utilisateur, mot de passe), mais ce champ supplémentaire est masqué à l'aide de CSS.
Typiquement, les bots essaieront d'entrer du texte dans tous les champs affichés dans le HTML, donc dans PHP j'ai vérifié que si le champ pot de miel n'était pas vide - je bannirais cette IP.
(C'était pour une page d'accueil pour un club de parachutisme avec une minuscule fonction d'administration pour mettre à jour les dates où nous allons sauter, etc. Je ne le recommanderais pas pour les applications sensibles)
Ajouter un Captcha ou ReCaptcha n'est pas une solution, c'est simplement un obstacle pour les pirates et les utilisateurs.
J'ai une très bonne vision avec mes lunettes et parfois je peux à peine distinguer le texte de l'image. J'imagine que quelqu'un dans le déni de sa vision va être furieux.
Tout ce que vous mettez en œuvre doit avoir un objectif spécifique, sinon vous finissez par jeter des tartes dans le ciel avec du caca et ces tartes finissent par atterrir directement sur vos utilisateurs.
Voici un peu de grain à moudre:
1
Problème
Les comptes d'utilisateurs sont piratés en raison de tentatives automatisées de force brute
Solution
Les comptes sont désormais verrouillés après 3 échecs de connexion
2
Problème
Tous les comptes d'utilisateurs ont été révélés et un bot essaie maintenant de forcer tous les comptes par force brute
Tous les comptes sont verrouillés en quelques secondes en raison de 3 échecs de connexion
Solutions? Abondant, mais avions-nous même besoin de passer à cette étape? Est-ce actuellement un problème?
Réfléchissez un instant à ce que votre captcha essaie d'accomplir. Voici l'objectif auquel je peux penser:
- Empêchez une attaque automatisée à grande échelle de pénétrer dans des comptes faibles
Voici une façon de faire qui rendra probablement vos utilisateurs plus heureux:
Si un ordinateur se connecte avec succès (en tant que Bob), définissez un cookie sur cet ordinateur afin que le serveur sache que l'ordinateur obtient 5 tentatives gratuites pour se connecter au compte de Bob sans avoir besoin du capcha.
Si l'ordinateur essayant de se connecter provient de la dernière IP connue de Bob, donnez à cette ip 5 des tentatives gratuites de connexion au compte de Bob sans avoir besoin du capcha.
L'idée ici est que la recherche de mot de passe de masse se produit généralement à partir d'ordinateurs ou d'ips qui ne se sont pas légitimement connectés au compte.
Cela peut probablement être amélioré en le combinant avec des idées d'autres réponses où vous donnez quelques "essais gratuits" à des comptes ou des ips.
Les systèmes CAPTCHA sont là pour différencier les robots automatisés des utilisateurs réels. Malheureusement, comme vous l'avez noté, ils ne sont pas très pratiques (en particulier pour les utilisateurs handicapés).
Que ce soit "une bonne idée" ou non dépend de votre cas d'utilisation, vraiment, bien qu'ils ne soient pas très efficaces avec les connexions utilisateur: ils ne sont pas très utiles pour empêcher les attaques par devinettes de mot de passe et la mise en œuvre d'un limiteur de débit dans l'application est plus pratique pour l'utilisateur lors de la mise en œuvre d'un TOTP PIN offre une meilleure sécurité.
Avoir une sorte de "preuve de travail" de votre client peut toujours être une très bonne idée si vous allez dépenser des ressources serveur pour lui et si ces ressources sont limitées. Un cas d'utilisation typique pour une telle requête est un système qui effectuera un travail pour des utilisateurs anonymes (par exemple, une application WHOIS basée sur le Web pourrait l'utiliser pour préserver les ressources).
Ajouter un captcha après 10 ou 100 tentatives infructueuses est inutile, car la plupart des bots actuels ont un compte deathbycaptcha et l'API pour dbc est vraiment facile à utiliser. Donc, montrer un captcha toutes les deux fois est une bonne chose, je pense.
Pour empêcher les attaques par force brute, vous feriez mieux de procéder comme suit.
1) Assurez-vous que les mots de passe sont suffisamment complexes. Si on leur en donne la possibilité, de nombreux utilisateurs utiliseront des mots de passe extrêmement simples, comme leur nom, etc.
2) IP de verrouillage après 5 tentatives de connexion infructueuses.
Il peut être utile d'ajouter un champ captcha à l'écran de récupération du mot de passe. Assurez-vous d'inclure suffisamment de texte pour expliquer aux utilisateurs comment cela fonctionne.