Mot de passe incorrect - nombre de tentatives - quel est le bon nombre à autoriser?
La plupart des sites et logiciels semblent avoir un verrouillage automatique ou un verrouillage horaire par défaut après 3 mauvais essais.
Je pense que le nombre pourrait être beaucoup plus élevé - ne pas autoriser de nouvelles tentatives consiste principalement à empêcher les attaques automatisées par force brute, je pense. La probabilité d'une attaque par force brute d'obtenir le bon mot de passe en 4 tentatives est presque la même que de l'obtenir en 3 tentatives - c'est-à-dire très très petit. Je pense que cela peut être maintenu beaucoup plus haut sans compromettre la sécurité.
Je sais qu'il existe d'autres stratégies comme l'augmentation du temps pour réessayer après chaque nouvelle tentative - mais je demande une stratégie simple comme le verrouillage après "n" tentatives - quel est le bon "n" maximum?
Sauf si vous disposez de moyens distincts pour restreindre l'accès au formulaire de connexion lui-même, une bonne base de référence est ne pas avoir de limite stricte. C'est parce qu'il est trop facile pour quelqu'un d'être complètement verrouillé de son compte.
C'est mauvais à cause du déni de service, évidemment, mais c'est aussi un problème de sécurité en soi. Cela augmentera les demandes d'assistance des personnes demandant que leurs comptes soient déverrouillés, et les personnes effectuant le déverrouillage deviendront habituées, et les attaques d'ingénierie sociale commençant par "hé, mon compte est verrouillé" deviennent beaucoup plus faciles.
Prolongez plutôt les délais d'expiration - mais pas à l'infini; juste assez pour limiter le nombre de suppositions à un montant raisonnable au fil du temps, compte tenu des exigences de complexité de votre mot de passe.
À mon avis, cela ne peut pas être répondu en général. Cela dépend de vos exigences en matière de convivialité, de sécurité et d'autres paramètres.
L'un des principaux facteurs est la taille de la plage de mots de passe possibles dans votre scénario spécifique. En supposant qu'un attaquant ne dispose pas d'informations supplémentaires sur le mot de passe et doit forcer brutalement la bonne combinaison, il a une chance de 1 sur le nombre de combinaisons de mots de passe possibles pour deviner le mot de passe spécifique.
Par exemple, avec un chiffre à 4 chiffres PIN nombre, il y a 10 000 combinaisons possibles (10 ^ 4). La probabilité de deviner une combinaison spécifique avec une tentative est de 1 à 10 000 ou 0,01%. Autoriser deux tentatives double la chance de le deviner à 0,02%.
C'est à vous de trouver le bon compromis pour votre scénario spécifique. Mais gardez à l'esprit que le forçage brutal n'est pas la seule méthode d'attaque que vous devrez peut-être considérer. Certains attaquants peuvent avoir des informations supplémentaires sur la cible et peuvent donc améliorer les chances de deviner correctement en essayant une combinaison plus probable (par exemple, si une personne ciblée utilise des informations personnelles dans son mot de passe et que l'attaquant les connaît).
Problème
Remarque initiale: je suis partisan des serveurs Web, mais bon nombre de ce qui est dit ici s'appliquera à d'autres types de services.
Le problème est le déni de service. Cela peut se produire de deux manières: 1) Les attaquants exécutent la force brute de telle manière qu'elle finit par saturer le serveur, et maintenant personne ne peut accéder au service. 2) Les utilisateurs (malveillants ou non) peuvent essayer trop de fois, entraînant le verrouillage de l'accès.
Autres considérations
Dire à l'utilisateur si l'erreur se trouve dans le nom d'utilisateur ou le mot de passe permettra à un attaquant de forcer les noms d'utilisateurs par dictionnaire/force brute. Bien que cela va à l'encontre de la convivialité, vous devriez opter pour la sécurité si les comptes sont destinés à être privés ou anonymes par défaut ※.
Dire à l'utilisateur que le compte est verrouillé facilitera la tâche des attaquants en bloquant de nombreux comptes (ce qui est une forme de déni de service et entraînera probablement de nombreux tickets de support). De plus, les comptes qui n'existent pas ne peuvent pas être verrouillés, ce qui permet aux attaquants de découvrir des comptes par cette méthode. Vous pouvez envisager de se moquer du verrouillage sur les faux comptes.
La découverte de comptes représente non seulement la moitié de l'attaque par force brute/dictionnaire, mais elle peut également être utile dans la future ingénierie sociale.
Une variante de l'attaque par force brute/dictionnaire consiste à essayer le même mot de passe (généralement un mot de passe statistique) contre un grand nombre de noms d'utilisateurs.
※: Les moteurs de recherche pourront-ils indexer les noms d'utilisateurs? S'ils le font, optez pour la convivialité (les attaquants ont de toute façon une liste de noms d'utilisateurs valides dans le cache du moteur de recherche). Évitez d'autoriser les moteurs de recherche à accéder à ces informations sur des sites où la connaissance de qui possède un compte peut être considérée comme une information sensible.
Solutions possibles
Il y a quelques choses courantes pour essayer de résoudre le problème:
- Ajouter un CAPTCHA
- Ajouter une nouvelle tentative
- Verrouiller le compte
- Verrouillez l'origine
- Authentification à deux facteurs
Il convient de noter que seul le verrouillage de l'adresse IP au niveau du pare-feu ou de la configuration du serveur Web aura un réel impact sur la charge du serveur. Pourtant, si vous ne verrouillez l'origine que lorsqu'il est associé au compte donné, la logique sera en code côté serveur. Il est également vrai pour le reste des versions qu'elles nécessitent un code côté serveur.
Ces solutions qui reposent sur le code côté serveur et ne protègent donc pas vraiment le serveur contre une attaque par inondation. Cela signifie que l'application principale de ces méthodes est aussi dissuasive.
Vocabulaire:
Pour le contexte de cet article, ces mots ont la signification mentionnée ici:
"Verrouiller": "empêcher l'accès jusqu'à ce qu'une authentification supplémentaire soit fournie", pour fournir des moyens d'authentification supplémentaires afin de suivre des étapes similaires - sinon les mêmes - que celles fournies aux utilisateurs qui ont oublié leur mot de passe.
"Origine": l'adresse IP, l'agent utilisateur ou d'autres techniques que le serveur peut utiliser pour identifier la source d'une connexion. En cas d'utilisation, il convient de mentionner dans la politique de confidentialité que le serveur enregistrera ces informations.
"Troisième canal": Courriel, SMS, application dédiée ou autre moyen de communication privé hors du contrôle du serveur.
Il convient également de noter que dans cette définition, le temps de nouvelle tentative n'est pas un verrou car il ne nécessite pas d'authentification supplémentaire de l'utilisateur mais attend à la place.
Et, car cela ne peut pas être dit suffisamment de fois , hachez et salez vos mots de passe.
CAPTCHA
Il convient de noter que toutes les solutions CAPTCHA ne sont pas visuelles. Certains sont auditifs, et même d'autres sont textuels (par exemple: "Combien de couleurs dans la liste violet, pingouin, bleu, blanc et rouge?").
Avantages
CAPTCHA est facile à mettre en œuvre à l'aide de solutions tierces. L'utilisation d'une solution tierce externalise également le problème pour rendre un CAPTCHA suffisamment solide.
Les inconvénients
L'utilisation d'un CAPTCHA peut devenir un inconvénient pour les utilisateurs légitimes qui peuvent avoir des problèmes pour taper le mot de passe. Le reCAPTCHA actuel atténue ce problème en utilisant l'analyse comportementale pour identifier les utilisateurs humains.
Un robot peut résoudre CAPTCHA par une intelligence artificielle intelligente, ou simplement en demandant à l'attaquant de le résoudre.
Temps de nouvelle tentative
Avantages
Le temps de nouvelle tentative a l'avantage de gagner du temps. Ainsi, il peut être combiné avec une notification sur un troisième canal pour alerter le propriétaire du compte.
Quelle action l'utilisateur peut-il entreprendre? Vous pouvez suggérer d'utiliser un mot de passe plus fort, mais cela ne résoudra pas vraiment le problème.
Comme alternative, envisagez de donner à l'utilisateur la possibilité de refuser l'accès à la machine de l'attaquant (c'est-à-dire de verrouiller la combinaison de l'origine et du compte) ※. Voir "Verrouiller l'origine".
※: il doit exiger une authentification et n'affecter que le compte courant. Des précautions doivent être prises pour éviter tout défaut qui pourrait conduire un compte à verrouiller un autre compte.
Les inconvénients
L'utilisation d'un temps de nouvelle tentative réduit la convivialité du service, car cela devient un inconvénient pour les utilisateurs légitimes qui peuvent avoir des problèmes pour taper le mot de passe. C'est pire que CAPTCHA car c'est un temps d'arrêt cognitif.
Les attaques par force brute/dictionnaire sont toujours viables si l'attaquant effectue une tentative toutes les heures environ. Les alternatives pour résoudre ce problème incluent des politiques de sécurité pour changer fréquemment le mot de passe (que l'utilisateur peut rendre inefficace en choisissant des mots de passe similaires) et IDS ou d'autres analyses pour détecter les attaquants (qui pourraient être contournés en distribuant l'attaque à partir de plusieurs sources - j'espère que c'est assez cher pour être dissuasif).
Verrouiller le compte
Avantages
Il résiste à la propagation d'une attaque dans le temps ou à de multiples origines.
Les inconvénients
Le verrouillage du compte peut entraîner le verrouillage d'un utilisateur légitime du compte en raison du nombre de tentatives infructueuses.
En outre, les tentatives infructueuses d'un attaquant dans un troisième emplacement verrouillent l'utilisateur légitime. La combinaison du verrouillage d'origine avec le verrouillage du compte permettrait un contrôle plus granulaire. Dans ce cas, le compte serait verrouillé uniquement pour l'origine à partir de laquelle l'accès est tenté.
Les attaques peuvent toujours affecter le système en obligeant les utilisateurs légitimes verrouillés à contacter le support ou à trouver un service alternatif.
Verrouillez l'origine
Avantages
Le verrouillage d'une origine, indépendamment du compte, a l'avantage de permettre d'arrêter les attaquants au lieu de punir les comptes.
Les inconvénients
Dans, le serveur devrait suivre l'origine des demandes et distinguer l'échec de la tentative réussie.
L'origine d'une attaque peut être partagée entre de nombreux utilisateurs (par exemple dans les cybercafés), et le verrouillage d'une origine peut signifier le verrouillage d'utilisateurs légitimes.
La combinaison du verrouillage d'origine avec le verrouillage du compte permettrait un contrôle plus granulaire. Dans ce cas, l'origine serait verrouillée uniquement pour le compte auquel il tente d'accéder, mais une origine verrouillée pour de nombreux comptes peut être verrouillée globalement.
Authentification à deux facteurs
Toutes les variantes de l'authentification à deux facteurs sont de puissants moyens de dissuasion par force brute/dictionnaire. Il existe deux variantes principales:
Envoyez un code via un troisième canal pour permettre l'authentification. Il ne devrait pas nécessiter de mesures supplémentaires pour empêcher la force brute de ce code, car il est destiné à être à usage unique et de courte durée.
Exiger un code de la clé matérielle/logicielle dédiée pour l'authentification. La clé doit fournir un code à usage unique qui autorise l'authentification.
Avantages
L'authentification à deux facteurs est la seule solution qui puisse rendre les attaques par force brute/dictionnaire inefficaces. Cela est accompli en exigeant un code à usage unique, qui étant à usage unique ne sera pas deviné en essayant plusieurs fois.
Les inconvénients
L'authentification à deux facteurs est souvent plus coûteuse à mettre en œuvre.
Que faut-il utiliser?
Il est logique d'ajouter une protection supplémentaire pour dissuader les attaques par force brute/dictionnaire. La nécessité de ces mesures est accrue dans les systèmes où l'espace de mot de passe est trop petit ※, ou si la force minimale des mots de passe est trop faible (par exemple les broches à quatre chiffres communes dans le secteur bancaire).
※: Il est bon de mettre un capuchon supérieur à la taille du mot de passe. De cette façon, le serveur ne sera pas choqué lors de la création d'un hachage coûteux sur le mot de passe. Et vous devez utiliser un hachage coûteux car il dissuadera les attaques par force de bure contre les codes de hachage volés .
CAPTCHA devrait être la première option, car il est très facile et peu coûteux à mettre en œuvre (en utilisant des solutions stables telles que reCAPTCHA).
Entre le temps de nouvelle tentative et les verrous, considérez que l'implémentation minimale viable est similaire: pour verrouiller un compte, vous ajoutez un champ à l'objet/enregistrement de compte le marquant comme verrouillé, puis vérifiez cela lors de l'authentification ... pour mettre un temps de nouvelle tentative, vous faites la même chose, sauf que ce que vous stockez est l'heure à laquelle l'authentification est à nouveau valide.
Il est logique d'atténuer les inconvénients en ajoutant ces mesures une fois que quelques tentatives ont échoué. Si tel est le cas, appliquez d'abord CAPTCHA car cela ne crée pas de temps d'arrêt cognitif pour l'utilisateur.
Entre les options de verrouillage, nous avons vu que la combinaison de l'origine et du compte est une meilleure alternative (mais aussi plus complexe) que l'une ou l'autre seule. La mise en œuvre nécessitera des journaux et des analyses.
Enfin, les authentifications à deux facteurs ont des avantages qui dépassent les solutions ci-dessus. Pourtant, il est le plus coûteux à mettre en œuvre car il nécessite une connexion à un service tiers (serveur de messagerie, SMS, application dédiée, matériel dédié, etc.).
Je suggérerais d'implémenter la journalisation et l'analyse et en fonction de ceux-ci décider si vous souhaitez implémenter le verrouillage ou si vous souhaitez implémenter l'authentification à deux facteurs.
Combien de tentatives?
Il y aura:
- n1 tente jusqu'à ce que catpcha apparaisse.
- n2 tentatives jusqu'à ce que le temps de nouvelle tentative apparaisse.
- n3 tente jusqu'à ce que le verrou soit appliqué.
Remarque: si vous utilisez l'authentification à deux facteurs, vous l'utilisez dès la première tentative.
Les valeurs de ces variables peuvent être modifiées à l'avenir en fonction de vos analyses. Pourtant, pour les défauts raisonnables, considérez:
n1 devrait être une estimation du nombre de tentatives qu'une personne peut faire si elle a des problèmes pour taper le mot de passe. 2 tentatives seraient le minimun n1 car cela explique l'erreur de base des plafonds. Remarque: gmail me permet 20 tentatives avant d'utiliser CAPTCHA.
n2 devrait être une estimation du nombre de tentatives qu'une personne ferait avant d'accéder au mécanisme de récupération. Il n'y a pas de minimun dur, en fait, il peut être appliqué dès que vous appliquez CAPTCHA et que vous avez des intervalles de temps croissants à attendre. À mon avis, n2 = 3 * n1 est un bon point de départ.
n3 devrait être une estimation du nombre de tentatives pour lesquelles il est plus probable qu'une attaque est en cours. Considérez que CATPCHA et le temps de nouvelle tentative devraient dissuader toute attaque manuelle, donc n3 n'a pas besoin d'être beaucoup plus élevé. À mon avis, n3 = 2 * n2 est un bon point de départ.
Remarque sur le temps de nouvelle tentative: l'intervalle que l'utilisateur doit attendre peut être augmenté à chaque tentative. Cela vous permet d'utiliser un très petit intervalle initial (par exemple 1 seconde) et d'accumuler à partir de là jusqu'à un plafond rigide (par exemple 1 jour).
Remarque sur le comptage des tentatives: vous devez éviter un débordement du nombre de tentatives. Si vous stockez le nombre de tentatives dans l'objet/enregistrement de compte, gérez le débordement. Si vous effectuez une requête sur les journaux pour obtenir le nombre de tentatives infructueuses à partir de la dernière tentative réussie, pensez à ajouter un intervalle de temps (qui limitera également le temps de requête).
Le nombre considéré comme "sûr" est assez arbitraire car le risque est basé sur la valeur des données, le niveau de complexité autorisé et appliqué, la longueur min/max du mot de passe et éventuellement d'autres mesures de sécurité que vous avez pu mettre en œuvre.
Le nombre typique se situe entre 3 et 10. Si vous implémentez des intervalles de temps croissants entre les tentatives infructueuses, vous pouvez aller vers le haut de gamme, mais uniquement si vous autorisez/encouragez ou appliquez une longueur et une complexité de mot de passe relativement élevées.
Ce que vous devez retenir, c'est que la plupart des gens ne proposent pas de mots de passe aléatoires. Au Royaume-Uni par exemple, la broche la plus courante est 1966 et une autre commune est 1066 - deux dates célèbres de l'histoire. Il y a bien sûr plus de choix dans un mot, mais les gens se retrouvent souvent avec des mots communs. Ainsi, autoriser 4 suppositions sur un mot de passe court est plus efficace que vous ne le pensez, surtout si votre système autorise de nouvelles tentatives après un délai d'attente.
Bien sûr, sur de nombreux sites, cela peut ne pas être très important si la sensibilité aux risques et aux données est faible.
Outre l'extension des délais d'expiration, un autre bon moyen d'améliorer la sécurité consiste à exiger un deuxième facteur d'authentification après quelques tentatives infructueuses. Envoyer souvent un code par e-mail ou par téléphone.
Vous pouvez également empêcher les tentatives de connexion de différents réseaux à court terme et surtout de différentes localités. C'est également une bonne idée de consigner et d'auditer les tentatives de connexion qui ont échoué.
Ces stratégies permettent d'éviter des niveaux élevés d'appels de support client tout en minimisant les risques.
Ce que j'utilise généralement est une formule de durée X en Y. 3 essais par seconde est un lock-out, mais 3 essais en 60 secondes sont très bien. 60 essais en 60 secondes, c'est mauvais, mais 60 essais en une journée, c'est bien.
Beaucoup dépendra de ce que vous essayez de protéger. En outre, s'il existe des règles externes qui doivent être suivies, telles que la politique de l'entreprise, HIPAA, etc., etc.
L'idée générale est que le processus devrait prendre suffisamment de temps pour que le "méchant" abandonne et passe à autre chose. Cela étant dit, il est important de ne pas lier les tentatives à une connexion, mais également à une plage IP et IP.
Cela dépend aussi beaucoup de votre processus de "restauration de l'accès". Disons que vous exécutez une API qui permet aux clients d'obtenir le statut d'expédition. En cas de verrouillage, ils doivent appeler le support et vérifier. Dans ce cas, j'autoriserais probablement quelque chose comme 120 tentatives tous les deux menuets et quelque chose comme 400 tentatives sur une période de 24 heures. Cela peut sembler élevé, mais avec la politique de "restauration", votre entreprise client pourrait être en panne pendant des heures ou des jours, si l'un de leurs scripts se détraque.
L'idée générale est d'arrêter ou d'allonger les attaques par force brute, mais pas de gêner les utilisateurs normaux, même lorsque les utilisateurs normaux utilisent de mauvaises informations d'identification.