Quelle est la différence entre la limitation des connexions et le verrouillage temporaire des comptes?
Je travaille actuellement sur la refonte d'une page de connexion. J'ai initialement suggéré que la connexion soit limitée, de sorte que des pauses (incrémentielles - en nombre de secondes) soient introduites entre chaque tentative de connexion échouée. L'idée est que cela nous permettra d'éviter de verrouiller le compte et de donner aux utilisateurs le temps de réfléchir à la réinitialisation de leur mot de passe et également de contrer toutes les attaques par force brute .
L'équipe de développement a suggéré que la limitation de la connexion n'aidera pas à prévenir les attaques par force brute, mais un verrouillage temporaire. Le verrouillage temporaire fonctionne de la même manière sauf que les pauses introduites sont (incrémentielles - en nombre de minutes et d'heures) donc je suis un peu confus ... ci-dessous est un exemple de la façon dont IBM QuickFile permet de configurer la connexion:
J'ai donc un certain nombre de questions:
Un verrouillage temporaire n'est-il qu'un autre terme pour la limitation de la connexion?
Quelle est la différence entre limitation de connexion et verrouillage temporaire ? Sont-ils les mêmes mais utilisent des paramètres de configuration différents. par exemple 3-6-12 secondes vs 5-10 - 20 minutes?
Quelles sont les implications de la conception d'interaction que je dois prendre en compte lors de l'adoption d'un mécanisme de verrouillage temporaire? Puis-je faire savoir à l'utilisateur quand il pourra réessayer? Peut-être en utilisant une forme d'indicateur visuel?
Quels sont les délais les plus adaptés pour les pauses entre les tentatives de connexion infructueuses qui ne frustreront pas l'utilisateur final? Ce post sur stakoverflow semble suggérer des secondes plutôt que des minutes
Quel impact cela a-t-il sur déni de service ?
Mise à jour: clarifications
Un peu plus pour clarifier! en cas d'échec d'une connexion, le bouton "réessayer" est désactivé pendant une durée de 3 secondes, après quoi il est activé. L'utilisateur tente de se connecter à nouveau et échoue, le bouton "réessayer" devient inactif pendant 6 secondes.
Le processus est répété pendant 5 tentatives consécutives et les messages d'erreur invitent les utilisateurs à réinitialiser leur mot de passe. À la 5e tentative, les utilisateurs se voient présenter un écran de réinitialisation de mot de passe.
D'un autre côté, les utilisateurs peuvent tenter de se connecter et avoir un nombre spécifié de tentatives après lesquelles le compte est "verrouillé" pendant une période de temps, par exemple 5 minutes, cela augmente à 10 minutes après un autre ensemble de tentatives.
Merci
A) Oui, vous l'avez compris. De même, ils résultent tous deux d'une tentative de connexion échouée, bien qu'ils diffèrent par des éléments tels que la journalisation, l'implémentation UX résultante et le moment où une est utilisée.
Si un utilisateur est temporairement exclu, cela vaut la peine d'être envoyé par e-mail. Vous devez leur envoyer un e-mail ou un SMS pour les informer que suffisamment de tentatives ont échoué pour justifier un verrouillage temporaire. C'est l'occasion de permettre à l'utilisateur d'intervenir dans le cas où ce n'est pas lui qui tente de se connecter.
Alternativement, vous pouvez utiliser simplement une minuterie de verrouillage en quelques minutes, mais exiger une action de l'utilisateur pour déverrouiller le compte serait plus idéal.
La limitation est plus pour le rythme. "tenez vos chevaux, respirez" et cela peut se faire sans même en informer l'utilisateur. Un simple élément spinner UI peut être utilisé pour empêcher l'utilisateur de soumettre des formulaires en double accidentellement et d'éviter des tentatives rapides sur une période de quelques secondes plutôt que des minutes ou des heures.
Cela peut également être utilisé comme une opportunité pour détecter les tentatives de bruteforce si l'attaquant ne passe pas par votre interface utilisateur. Si 3 tentatives sont effectuées par seconde mais que votre interface utilisateur n'autorise qu'une seule tentative toutes les 3 secondes, quelque chose ne va pas.
"Limitation" et "verrouillage temporaire" sont exactement la même chose.
Il est probable, cependant, que votre équipe de développement ait mal compris les concepts et a supposé que vous vouliez dire "étrangler" comme la plupart des autres réponses ici (à l'exception de @ R15 , bien que ce soit moins une réponse et plus de considérations importantes).
Le point important qui leur manque est simplement le suivant:
L'ensemble Raison d'être du verrouillage temporaire [~ # ~] est [~ # ~] étranglement de la connexion.
Le verrouillage du compte n'est pas une punition pour l'utilisateur, ni n'accorde automatiquement au compte Magik Powers of Immunity de toutes les attaques pendant qu'il est verrouillé.
La raison pour laquelle le verrouillage temporaire fonctionne, c'est qu'il définit effectivement un minimum de temps pour effectuer X nombre de tentatives de connexion.
En d'autres termes, un nombre maximum de tentatives de connexion au cours de la période Y.
Donnons un exemple:
Sans protection par force brute, disons qu'un attaquant peut tenter 1000 mots de passe/seconde. Selon ce XKCD classique , la plupart des mots de passe "complexes" auraient jusqu'à 28 bits d'entropie. À 1000 suppositions/seconde, cela prendrait environ 3 jours à la force brute.
Supposons maintenant que vous disposez d'une protection par force brute (limitation/verrouillage du compte): After X passwords, lock the account for Y amount of time. Ou formulé comme étranglement: Allow only X passwords every Y amount of time.
Ce sont clairement les mêmes .... que Y soit 30 secondes ou 30 minutes. Et ils fonctionneraient tous les deux.
Mais laisse jouer ...
- Pour le rendre facile, nous allons définir les X = 10 ci-dessus (mots de passe incorrects autorisés), Y = 10 minutes (temps de verrouillage). À ce rythme (c'est en fait 1 supposition par minute, en moyenne, juste pour faciliter les choses) - il faudra un peu plus de 500 ans pour deviner (en moyenne).
- D'accord, baissons les paramètres ... X = 5 suppositions, Y = 30 secondes. Le même mot de passe prendrait un peu plus de 50 ans (puisque, en moyenne, votre taux d'accélération est de 10 suppositions par minute).
- Ou, comme vous semblez l'avoir voulu, X = 1 supposition par Y = 10 secondes (?): Avec une moyenne de 6 suppositions par minute, il faudrait environ 85 ans pour forcer brutalement le mot de passe ...
Bien sûr, vous pouvez régler ces paramètres selon le sens de votre système, et surtout, comme @ R15 l'a dit plus tôt, cela devrait être en relation avec la force des mots de passe de vos utilisateurs.
Cependant, que vous considériez qu'il s'agit de "verrouillage de compte" ou de "limitation de compte" est exactement la même chose, car la première n'est qu'une simple mise en œuvre pour atteindre la seconde.
Une autre chose à considérer est que le taux de tentative moyen autorisé (imposé par la limitation ou le verrouillage) devrait en théorie être lié au temps de couverture effectif des mots de passe des utilisateurs.
Autrement dit, la limitation/verrouillage devrait être suffisante pour empêcher une attaque par force brute via l'interface Web de réussir avant que l'utilisateur ne modifie son mot de passe.
Ou, autrement dit, la décision concernant les heures est liée à la complexité de votre mot de passe et à la fréquence des changements.
De toute évidence, cependant, si vous auditez les journaux, vous devriez être en mesure d'identifier les attaques lentes contre des comptes spécifiques et de faire quelque chose avant qu'il y ait une probabilité de deviner le mot de passe.
La limitation est utilisée lorsque le verrouillage n'est pas une option. Cela se produit en particulier lorsqu'il est impératif d'éviter d'impliquer des opérations de support (nouvelles startups avec un nombre élevé d'utilisateurs), ce qui donne plus de poids à la sécurité qu'à la continuité des activités, la conformité ou des raisons de sécurité (le verrouillage peut mettre en danger la sécurité de quelqu'un).
La principale différence est qu'un "compte verrouillage" est basé sur les comptes d'utilisateurs et la limitation des tentatives de connexion peut également être effectuée en limitant les tentatives par client.
Limiter les tentatives de connexion par client aide par exemple si un seul client malveillant ne cible pas un compte spécifique mais essaie un nom de compte différent à chaque tentative (ou jusqu'à ce que le compte soit verrouillé).
Si vous limitez les tentatives de connexion par compte, cela revient essentiellement à un verrouillage temporaire.