L'affichage du nombre de nouvelles tentatives de mot de passe représente-t-il un risque pour la sécurité?
Certains sites Web affichent un nombre de tentatives de mot de passe restant lorsque j'entre des mots de passe incorrects plus de deux fois. Par exemple, afficher qu'il reste 3 tentatives jusqu'à ce que mon compte soit verrouillé. Est-ce dangereux du point de vue de la sécurité?
Verrouiller les comptes est une mauvaise idée en premier lieu. Il pourrait sembler que vous sécurisez votre organisation en empêchant les "mauvaises personnes" qui sont "deviner" les mots de passe en utilisant des attaques par force brute, mais qu'avez-vous vraiment résolu? Même avec cette politique et une base d'utilisateurs parfaite qui ne commet jamais d'erreurs de sécurité, un attaquant peut mener une attaque par déni de service sur votre organisation en utilisant à plusieurs reprises le mot de passe "aaa" pour verrouiller les comptes des utilisateurs critiques. Considérez ce qui se passe si votre attaquant obtient une copie de la liste des noms d'utilisateur pour l'ensemble de votre service informatique: soudain, l'informatique elle-même - l'organisation qui serait autrement en mesure de déverrouiller d'autres utilisateurs - est elle-même complètement fermée.
Tenez toujours compte du modèle de menace avant de mettre en œuvre une politique. Un "méchant" déterminé à blesser votre organisation trouvera des vecteurs d'attaque alternatifs. Votre politique de verrouillage ne déroutera même pas un acteur d'État-nation (comme la Russie ou la Chine ou la NSA); un pirate déterminé trouvera simplement d'autres moyens de contourner ce problème (comme l'ingénierie sociale); et cela ne fera que nuire aux utilisateurs légitimes de votre service, quelle que soit la valeur basse ou élevée que vous définissez le compteur de verrouillage.
Morale de l'histoire: Ne verrouillez pas les comptes. À la place, faites ce que Apple fait avec l'iPhone: chaque tentative de connexion double le délai de connexion, de sorte que après une douzaine d'échecs, vous devez attendre une heure entre chaque tentative successive. C'est assez long pour empêcher les "méchants" d'effectuer des attaques par force brute, mais toujours assez court pour qu'un utilisateur légitime puisse passer cette heure à déterminer ce que mot de passe était et le taper correctement après le déjeuner - ou contacter le service informatique et demander de l'aide par excuses. (De même, les politiques "inondation" peuvent souvent être mises en œuvre au niveau de l'adresse IP dans votre pare-feu, pas seulement au niveau du compte d'utilisateur dans logiciel, si vous êtes préoccupé par un attaquant dédié essayant de forcer de nombreux comptes différents.)
Et si vous ne verrouillez pas les comptes, vous n'avez pas besoin de avoir un compteur - ou afficher.
[ voir aussi: cette excellente réponse sur une question similaire]
Cela dépend de votre mécanisme de verrouillage. Si les connexions invalides sont réinitialisées après un certain temps ET qu'un compte verrouillé n'est pas déverrouillé, l'affichage d'un compteur peut aider un attaquant à ne pas verrouiller un compte. Mais un attaquant qualifié aura déterminé la politique de verrouillage à l'avance et en tiendra compte lors de la recherche du mot de passe. L'impact est donc limité.
En outre, s'appuyer sur cela pour protéger votre mécanisme de connexion ne sert à rien. Vous devez avoir une politique de mot de passe décente et une politique de verrouillage correspondant. Si la politique de mot de passe est solide, un attaquant devra deviner un grand nombre de fois avant de bien faire les choses. Si vous verrouillez un compte après 20 tentatives, vous avez peu de chances d'être compromis.
Vous devez vous demander: quel est l'avantage de montrer ces informations à un véritable utilisateur? Souvent, ces problèmes de verrouillage se produisent car le nombre d'essais est trop faible. 3 ou 5 sont des choix courants. NIST (actuellement indisponible en raison de la fermeture du gouvernement, donc pas de référence directe pour l'instant) suggère moins de 100 tentatives .
Le NIST a un point: pensez à un mot de passe qu'aucun attaquant ne devinera en 3 tentatives, mais qu'il devinera en 100 tentatives. Tous les attaquants utilisent des dictionnaires et des approches différents. Si un mot de passe n'est pas sûr de résister à 100 suppositions, il peut également être violé en utilisant moins de tentatives - bien que cela soit moins probable. Par conséquent, une bonne politique de mot de passe est indispensable.
J'ajouterai les références NIST lorsque le site reviendra. Troy hunt a quelques bons articles de blog qui résument les mécanismes de mot de passe et de connexion. Il est également fan des directives du NIST.
En principe, non, cela ne devrait pas être un risque pour la sécurité. Si c'était le cas, alors vous dépendriez de la sécurité par l'obscurité (informations cachées).
Cacher un compte serait, au mieux, un inconvénient mineur pour un adversaire.
En revanche, masquer un nombre peut être un inconvénient important pour les utilisateurs légitimes. Il n'est pas rare que j'entre parfois le mauvais mot de passe, puis le ressaisis plusieurs fois en supposant que j'ai fait une faute de frappe. Si je sais que je serai bloqué par une autre tentative incorrecte, je vais chercher mon mot de passe et le copier/coller ou le taper soigneusement. Si, cependant, je me verrouille involontairement hors de mon compte, je dois maintenant faire face à beaucoup de problèmes supplémentaires pour le déverrouiller.
Pour donner une autre perspective à ce sujet: cela n'a pas d'importance pour un attaquant qualifié.
Comment les comptes en ligne sont-ils compromis aujourd'hui 1? Il existe deux variantes d'une technique couramment utilisées.
Les bases de données avec hachage de mot de passe (ou mots de passe en texte clair) sont volées et sont piratées hors ligne par les attaquants. Après avoir réussi à casser un hachage, le mot de passe correct est envoyé au mécanisme de connexion lors du premier essai, ce contrôle est donc inefficace.
Il peut s'agir de la base de données du service en question ou de la base de données d'un autre service. Malheureusement, les gens ont tendance à réutiliser leurs mots de passe avec plusieurs services, donc les chances sont élevées, qu'une fois qu'un mot de passe est associé à une adresse e-mail, il peut être utilisé sur un autre site. Un attaquant peut avoir le choix entre deux ou trois mots de passe, mais probablement pas 20. Encore une fois, ce contrôle est inefficace.
Alors quel niveau de sécurité ce contrôle établit-il? Le niveau nécessaire pour se protéger des script kiddies inexpérimentés, des ex-partenaires malveillants et des parents curieux qui veulent jeter un œil à votre compte personnel et essayer cinq mots de passe au hasard. Pas plus, mais pas moins.
1 Ensuite, il y a bien sûr d'autres techniques plus "avancées" comme le keylogging, (spear) -phishing, MitM etc. qui ne sont pas non plus atténuées par ce contrôle.
Seul deux scénarios sont possibles, mais plutôt le fait de montrer que le risque de politique de temps de verrouillage du compte est supérieur au temps de verrouillage.
Par exemple.
une fois, vous pouvez configurer l'hydre ou un autre outil pour forcer la connexion et attendre 3 tentatives. si vous ne disposez pas d'un temps de verrouillage suffisant, cela peut entraîner un compromis sur le compte.
si vous avez environ 30 minutes de verrouillage, alors nous pouvons configurer l'outil pour la force brute et attendre trois tentatives, il faudra des années pour déchiffrer le mot de passe.
pour conclure, leur aucun risque implique d'afficher la tentative de verrouillage du compte.
Je penche en général vers le moins d'informations que vous donnez à un attaquant, mieux c'est. Comme @ security-beast l'a mentionné, un outil peut être configuré pour attendre la durée appropriée. Leur donner les informations pour cette configuration n'est pas nécessairement idéal.
Cependant, vous devez équilibrer cela avec les besoins de vos utilisateurs. Trouvez-vous que les administrateurs système passent un temps excessif à déverrouiller des comptes parce que vos utilisateurs continuent de les verrouiller? Si tel est le cas, votre analyse peut indiquer que vous obtenez plus d'avantages en affichant le nombre de nouvelles tentatives à vos utilisateurs afin qu'ils sachent quand ils doivent attendre avant de verrouiller leurs comptes. Dans d'autres cas, l'inverse sera vrai, mais dans un cas comme dans l'autre, la réponse devrait être le résultat d'une analyse objective des compromis pour le système particulier.
J'espère que cela t'aides.
À un moment donné, j'étais dans une entreprise où ils avaient juste quelques gars pour tester leur sécurité. L'une de ces choses que ces gars-là ont découvert est qu'il n'y avait pas de verrouillage de compte quand il y avait trop de mots de passe incorrects. Cependant, pour le plus grand plaisir du CISO, ils n'ont pas pu prouver qu'ils pouvaient réellement entrer en forçant le mot de passe par brute. La raison en était que le verrouillage du compte était silencieux et a duré environ 15 minutes.
Demandez-vous ce que vous gagnez en affichant un tel message et ce que vous perdez en sécurité en le faisant. Il est parfaitement valable de ne donner aucune notification de verrouillage d'un compte en raison d'un trop grand nombre de tentatives de connexion incorrectes. Si vous donnez un tel message, vous n'aurez qu'à aider un attaquant à déterminer quand il perd son temps à forcer brutalement. Si vous ne le faites pas, ils sont moins susceptibles de le découvrir, mais cela pourrait entraîner davantage d'appels/de courriers électroniques vers votre service d'assistance, ce qui pourrait être coûteux. Une FAQ ou page d'aide pourrait réduire cela.
L'implémentation du compte à rebours signifiera probablement plus de code et plus de code signifie plus de bugs. Ce n'est pas quelque chose que vous voulez dans un mécanisme de sécurité. Ajoutez à cela que vous l'implémentez mal, cela pourrait permettre aux attaquants d'énumérer les noms d'utilisateur, ce qui est doublement problématique s'il s'agit d'adresses e-mail. Enfer, si vous l'implémentez en utilisant un cookie non signé, cela pourrait en fait donner à l'attaquant la possibilité d'empêcher un verrouillage.
En général, votre sécurité sera améliorée si vos messages d'erreur donnent le moins d'informations possible.
Le risque de sécurité est subjectif, il dépendra de ce que vous essayez de protéger l'objectif du contrôle de sécurité et de tout autre contrôle de sécurité en place qui atténue ou compense le risque.
Sur la base de cela, différentes sociétés/entreprises auront une acceptation différente du même risque.
Si, d'une manière générique, en indiquant le nombre de tentatives que vous avez encore, vous ne risquez pas d'imposer un risque (par exemple: PIN dans votre carte à puce pour passer des appels téléphoniques) Dans d'autres situations, cela peut être un risque (par exemple: essayer de forcer l'accès au téléphone portable par force brute) où vous pouvez vous arrêter avant la dernière tentative et attendre un certain temps pour que l'utilisateur réinitialise le compteur avec un accès valide ...
Vous devez vérifier l'objectif du contrôle de sécurité, ce que vous essayez de protéger et les contrôles de sécurité que vous avez mis en place pour compenser ou au moins surveiller les situations anormales.
Sur la base de tout cela, vous pouvez décider s'il s'agit d'un risque acceptable ou non pour vos spécificités.