À moins que vous n'ayez des moyens séparés pour restreindre l'accès au formulaire de connexion lui-même, une bonne base est ne pas avoir de limite stricte . C'est parce qu'il est beaucoup trop facile pour quelqu'un d'être complètement bloqué sur 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 le déverrouillage de leur compte, et les personnes qui effectuent le déverrouillage s'habitueront, et les attaques d'ingénierie sociale commençant par "hé, mon compte est verrouillé" deviendront beaucoup plus faciles.

Au lieu de cela, prolongez les délais, mais pas indéfiniment; 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 l'étendue de la gamme de mots de passe possibles dans votre scénario spécifique. En supposant qu'un attaquant n'a pas d'autres informations sur le mot de passe et doit forcer brutalement la bonne combinaison, il a une chance de 1 au nombre de combinaisons de mots de passe possibles pour deviner le mot de passe spécifique.

Par exemple avec un 4 chiffres Numéro PIN il y a 10 000 combinaisons possibles (10 ^ 4). La probabilité de deviner une combinaison spécifique en une seule tentative est de 1 à 10 000 ou 0,01%. Autoriser deux tentatives double les chances 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 attaque méthode que vous devrez peut-être envisager. 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 en a connaissance).

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ée et appliquée, la longueur minimale / maximale du mot de passe et éventuellement d'autres mesures de sécurité que vous avez peut-être implémentées.

Le nombre typique est compris entre 3 et 10. Si vous implémentez des intervalles de temps croissants entre les tentatives infructueuses, vous pouvez aller vers l'extrémité supérieure, mais seulement si vous autorisez / encouragez ou appliquez une complexité & de longueur de mot de passe relativement élevée. p>

Ce dont vous devez vous souvenir, 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 plus à choisir en un mot bien sûr, mais les gens se retrouvent encore souvent avec des mots communs. Donc, autoriser 4 suppositions sur un mot de passe court est plus efficace que vous ne le pensez, surtout si votre système autorise d'autres tentatives après un délai d'expiration.

Bien sûr, sur de nombreux sites, cela n'a pas beaucoup d'importance si le risque et la sensibilité des données est faible.

En plus d'allonger les délais d'expiration, un autre bon moyen d'améliorer la sécurité est d'exiger un deuxième facteur d'authentification après quelques tentatives infructueuses. Envoi souvent d'un code par e-mail ou par téléphone.

Vous pouvez également empêcher les tentatives de connexion à partir de différents réseaux en une courte succession et en particulier de différentes localités. C'est également une bonne idée de consigner et d'auditer les tentatives de connexion infructueuses.

Ces stratégies permettent d'éviter des niveaux élevés d'appels au support client tout en minimisant les risques.

Problème

Note initiale: je suis partisan des serveurs Web, mais beaucoup 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 que cela 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

1. Informer l'utilisateur si l'erreur est dans le nom d'utilisateur ou le mot de passe permettra à un attaquant de force brute / dictionnaire des noms d'utilisateur. Bien que cela va à l'encontre de la convivialité, vous devez opter pour la sécurité si les comptes sont destinés à être privés ou anonymes par défaut ※.

2. Dire à l'utilisateur que le compte est verrouillé sera permettent aux attaquants de créer plus facilement des problèmes en verrouillant de nombreux comptes (ce qui est une forme de déni de service, et cela conduira 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.

3. La découverte de comptes n'est pas seulement la moitié de l'attaque par force brute / dictionnaire, mais elle peut également être utile dans le futur de l'ingénierie sociale.

4. Une variante de l'attaque par force brute / dictionnaire consiste à essayer le même mot de passe (généralement un mot de passe statistiquement commun) 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 à de telles informations sur des sites où savoir qui possède un compte peut être considéré comme une information sensible.

Solutions possibles

Il y a quelques éléments communs pour essayer de résoudre le problème :

• Ajouter un CAPTCHA
• Ajouter une heure de nouvelle tentative
• Verrouiller le compte
• Verrouiller l'origine
• Authentification à deux facteurs

Il est à noter que seul le verrouillage de l'adresse IP au niveau du pare-feu ou de la configuration du serveur Web aura un impact réel sur la charge du serveur. Pourtant, si vous ne verrouillez l'origine que lorsqu'il est associé au compte donné, la logique sera dans le code côté serveur. Il est également vrai pour le reste des solutions qu'elles nécessitent du code côté serveur.

Ces solutions reposent sur du code côté serveur et ne protégeront donc pas vraiment le serveur d'une attaque par inondation. Cela signifie que l'application principale de ces méthodes est comme 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 autre authentification soit fournie", pour fournir des moyens d'authentification supplémentaires pour 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. S'il est utilisé, il doit être mentionné dans la politique de confidentialité que le serveur enregistrera ces informations.

• "Troisième canal": e-mail, SMS, application dédiée ou autre support privé communication en dehors du contrôle du serveur.

Il convient également de noter que selon cette définition, le temps de nouvelle tentative n'est pas un verrou car il ne nécessite pas d'authentification supplémentaire de utilisateur mais attendez à la place.

Et, parce que cela ne peut pas être dit assez de fois , hachez et salez vos mots de passe.

CAPTCHA

Il est à noter que toutes les solutions CAPTCHA ne sont pas visuelles. Certains sont auditifs, et d'autres encore 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 puissant.

Inconvénients

L'utilisation d'un CAPTCHA peut devenir un inconvénient pour les utilisateurs légitimes qui peuvent avoir des difficultés à saisir le mot de passe. Le reCAPTCHA actuel atténue ce problème en utilisant l'analyse de comportement pour identifier les utilisateurs humains.

Un robot peut résoudre CAPTCHA par une IA intelligente, ou simplement en demandant à l'attaquant de le résoudre.

Temps de réessayer

Avantages

Le temps de réessai 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 de la machine attaquante (c'est-à-dire de verrouiller la combinaison de origine et compte) ※. Voir "Verrouiller l'origine".

※: Cela devrait nécessiter une authentification et n'affecter que le compte actuel. Des précautions doivent être prises pour éviter tout défaut susceptible d'entraîner le verrouillage d'un autre compte par un compte.

Inconvénients

L'utilisation d'un délai de réessai réduit la convivialité du service, car cela devient un inconvénient pour utilisateurs légitimes qui peuvent avoir des problèmes pour saisir le mot de passe. C'est pire que CAPTCHA car il s'agit d'un temps d'arrêt cognitif.

Les attaques par force brute / dictionnaire sont toujours viables si l'attaquant effectue une tentative une fois par heure 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 - espérons-le. assez cher pour être dissuasif en soi).

Verrouiller le compte

Avantages

Il résiste à la propagation d’une attaque dans le temps ou à plusieurs origines.

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.

De plus, les tentatives infructueuses d'un attaquant dans un troisième emplacement verrouillent l'utilisateur légitime. La combinaison du verrouillage de l'origine avec le verrouillage du compte permettrait un contrôle plus granulaire. Dans ce cas, le compte ne serait verrouillé que 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 l'assistance ou à trouver un autre service.

Verrouiller l'origine

Avantages

Verrouiller une origine, indépendamment du compte, a l'avantage de permettre d'arrêter les attaquants au lieu de punir les comptes.

Inconvénients

Dans, il faudrait que le serveur suive l'origine des requêtes et distingue les échecs des tentatives réussies.

L'origine d'une attaque peut être partagée entre de nombreux utilisateurs (par exemple, dans Les cafés Internet), et le verrouillage d'une origine peut signifier le verrouillage des utilisateurs légitimes.

La combinaison du verrouillage de l'origine avec le verrouillage du compte permettrait un contrôle plus granulaire. Dans ce cas, au début, l'origine ne serait verrouillée que pour le compte auquel elle 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 matériel / logiciel dédié clé 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 peut réellement rendre brute- attaque de force / dictionnaire inefficace. Ceci est accompli en exigeant un code à usage unique, qui étant à usage unique ne sera pas deviné en essayant plusieurs fois.

Inconvénients

L'authentification à deux facteurs est souvent plus coûteuse à implémenter.

Quoi utiliser?

Il est judicieux d'ajouter une protection supplémentaire pour dissuader les attaques par force brute / dictionnaire. Le besoin de ces mesures est accru 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 courantes dans les banques).

※: Il est bon de mettre un plafond supérieur à la taille du mot de passe. De cette façon, le serveur ne sera pas bloqué lors d'un hachage coûteux sur le mot de passe. Et vous devriez utiliser un hachage coûteux car il dissuadera les attaques de force 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 établies 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 du compte le marquant comme verrouillé, puis vérifiez que lors de l'authentification ... pour mettre un temps de relance, 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 l'inconvénient d'ajouter 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 combiner l'origine et le compte est une meilleure alternative (mais aussi plus complexe) que l'un ou l'autre seul. La mise en œuvre nécessitera des journaux et des analyses.

Enfin, les authentifications à deux facteurs présentent des avantages qui surpassent les solutions ci-dessus. Pourtant, c'est le plus coûteux à mettre en œuvre car il nécessite une connexion à un service tiers (serveur de messagerie, service SMS, application dédiée, matériel dédié, etc.).

Je suggérerais de mettre en œuvre la journalisation et l'analyse et en fonction d'eux, décidez si vous souhaitez implémenter le verrouillage ou si vous souhaitez implémenter l'authentification à deux facteurs.

Combien de tentatives?

Il y aura:

• n ₁ tentatives jusqu'à ce que catpcha apparaisse.
• n ₂ tentatives jusqu'à ce que l'heure de nouvelle tentative s'affiche.
• n ₃ tentatives jusqu'à ce que le verrouillage 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 ultérieurement en fonction de vos analyses. Cependant, pour des valeurs par défaut raisonnables, considérez:

• n ₁ devrait être une estimation du nombre de tentatives qu'une personne peut faire si elle a des problèmes pour saisir le mot de passe . 2 tentatives serait le minimun n ₁ car cela explique l'erreur de base des caps. Remarque: gmail me permet 20 tentatives avant d'utiliser CAPTCHA.

• n ₂ devrait être une estimation du nombre de tentatives qu'une personne ferait avant d'aller à mécanisme de récupération d'accès. Il n'y a pas de minimum 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, n ₂ = 3 * n ₁ est un bon point de départ.

• n _{3 sub> doit être une estimation du nombre de tentatives pour lesquelles il est plus probable qu'une attaque soit faite. Considérez que CATPCHA et le temps de relance devraient dissuader toute attaque manuelle, donc n 3 n'a pas besoin d'être beaucoup plus élevé. À mon avis, n 3 = 2 * n 2 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 de construire à partir de là jusqu'à un plafond fixe (par exemple 1 jour).

Remarque sur le comptage des tentatives: Vous devez éviter un débordement dans le les tentatives comptent. Si vous stockez le nombre de tentatives dans l'objet / l'enregistrement de compte, gérez le débordement. Si vous effectuez une requête sur les journaux pour obtenir le nombre de tentatives infructueuses de la dernière réussite, pensez à ajouter un intervalle de temps (qui limitera également la durée de la requête).

Ce que j'utilise généralement est une formule de temps X en Y. 3 essais une seconde est un verrouillage, mais 3 essais en 60 secondes, c'est bien. 60 essais en 60 secondes, c'est mauvais, mais 60 essais par jour, c'est bien.

Beaucoup dépendra de ce que vous essayez de protéger. De plus, s'il y a des règles externes qui doivent être suivies comme la politique de l'entreprise, la HIPAA, etc.

L'idée générale est que cela devrait rendre le processus suffisamment long pour que le "méchant" abandonne et passe. 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 d'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 l'assistance et vérifier. Dans ce cas, j'autoriserais probablement quelque chose comme 120 tentatives tous les deux minutes et quelque chose comme 400 tentatives sur une période de 24 heures. Cela peut sembler élevé, mais avec la politique de «restauration», votre activité client peut ê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 de prolonger 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.

J'aime la limite de 3 (par heure. et peut-être 6-9 échecs par jour, 12-18 par quinzaine), mais les tentatives en double avec le même mot de passe (dans 3 groupes) ne doivent pas être comptées. Si vous avez effectivement oublié votre mot de passe, vous ne vous connectez probablement pas souvent, donc cela peut attendre. Mieux vaut que quelqu'un fasse trop de tentatives par jour pour le deviner.

Mais dans ce cas, si vous êtes déjà verrouillé, vous saurez que quelqu'un a essayé de le deviner, et nous besoin d'une stratégie sur la façon de gérer cela, en particulier lorsque vous souhaitez vous connecter.