Question:
Un acteur malveillant peut-il verrouiller l'utilisateur réel en essayant délibérément des mots de passe incorrects toutes les X minutes?
yeti
2017-04-05 20:35:44 UTC
view on stackexchange narkive permalink

Certains sites Web verrouillent un utilisateur après une série de tentatives de mot de passe incorrectes, par exemple pendant 15 minutes. Si un acteur malveillant le sait, peut-il délibérément essayer de se connecter avec des mots de passe incorrects toutes les 15 minutes pour empêcher la personne réelle de se connecter? S'agit-il d'une menace réelle et si oui, comment les sites Web peuvent-ils s'en protéger?

J'ai vu un site Web qui verrouillerait l'utilisateur jusqu'à ce qu'il clique sur un lien dans son e-mail.
Quand j'étais au lycée, le domaine NT vous bloquait pendant 15 à 20 minutes après 3 à 5 tentatives incorrectes, et les noms d'utilisateur étaient basés sur les vrais noms des gens.Si vous saviez comment saisir les touches pour vous déconnecter (Ctrl-Alt-Suppr, L, Entrée), vous pouvez verrouiller le compte de quelqu'un sur votre propre ordinateur, marcher derrière lui, tendre la main et le déconnecter avant qu'il ne puisse réagir.
La plupart des sites bancaires en ligne que j'ai eu le "plaisir" d'utiliser semblent y être vulnérables.Après 3 tentatives infructueuses, le compte est définitivement verrouillé.Vous devez vous rendre à la banque et demander personnellement sa réouverture - ils ne facturent aucun frais pour cela, mais c'est un problème.Maintenant, étant donné qu'il s'agit de finances, on pourrait dire que c'est OK.MAIS, dans presque TOUTES les banques que j'ai utilisées la première barre, le nom d'utilisateur est JUSTE un nombre.Une personne malveillante pourrait très facilement verrouiller les comptes à gauche et à droite pour le "lolz".
@Shaamaan Il y a quelques années, je suis tombé sur ça, mais j'ai découvert que j'avais en fait mal mémorisé mon nom d'utilisateur, donc j'avais verrouillé quelqu'un d'autre sans le vouloir.
Cela se produit avec les streamers RuneScape populaires.Le système vous verrouille après trop de tentatives de connexion incorrectes.
Sur mes très petits serveurs Web (pensez à 300 à 400 utilisateurs * en haut *), je fais généralement des verrouillages permanents automatisés mais basés sur IP.Cela semble suffisant pour mes cas d'utilisation occasionnels, et je pense qu'au cours des 6 dernières années, je n'ai dû débloquer manuellement que 3 ou 4 personnes.
J'ai arrêté des systèmes de production en essayant accidentellement de me connecter à des comptes système avec des mots de passe incorrects.Quelque chose à garder à l'esprit si vous créez une politique de verrouillage de compte pour les comptes système.:)
@Shaamaan Et une certaine banque qui restera sans nom avait encore pire, les utilisateurs étaient numérotés * séquentiellement *, donc n'importe qui pouvait verrouiller toute la banque avec un peu de script.
le site Apple ID vous bloquera après des tentatives de connexion infructueuses répétées ... et si vous avez une authentification à 2 facteurs, vous devez avoir le code de récupération qui vous a été donné lors de la première configuration du 2FA.Si vous ne l'avez pas, vous perdrez l'accès à votre compte.
D'après ma propre expérience, il y a 5 à 8 ans, on appelait cela des comptes "gelés", et de nombreux sites dans les communautés de jeux en particulier étaient vulnérables à cela.Beaucoup ont utilisé cela comme une gêne pour leurs rivaux / ennemis.
@Shaamaan ma banque me laisse choisir (et changer) mon nom d'utilisateur.J'utilise un gestionnaire de mots de passe à cet effet.Le nom d'utilisateur appartient à la même classe d'entropie que le mot de passe (16 caractères de long).Il est peu probable que je sois en lock-out.
@TannerSwett depuis quand les comptes système ont-ils des mots de passe ou des identifiants?
C'est ce qu'on appelle une attaque par déni de service (DOS), et c'est en effet une menace réelle.
@emory Tant mieux pour vous!Tout le monde n'est pas aussi chanceux.Une de mes banques permet aux utilisateurs de choisir un alias pour faciliter la connexion ... malheureusement, cela ne supprime pas le nom d'utilisateur numérique qu'ils attribuent ...
Six réponses:
hax
2017-04-05 22:07:41 UTC
view on stackexchange narkive permalink

La protection de connexion par force brute peut être appliquée de trois manières:

  • Verrouillage temporaire
  • Verrouillage permanent
  • CAPTCHA

À mon avis, CAPTCHA est la solution la plus raisonnable pour éviter le risque de force brute ainsi que le déni de service dû au verrouillage de compte. Vous avez peut-être vu un CAPTCHA apparaître sur les pages de connexion de Facebook et Gmail au cas où vous entrez un mot de passe erroné plus de trois ou quatre fois. C'est un moyen décent d'empêcher les bots de faire du bruteforcing et en même temps d'éviter de verrouiller les utilisateurs.

Le verrouillage permanent n'est pas une solution nouvelle, et cela ajoute beaucoup de frais généraux opérationnels à l'équipe de support client s'ils le doivent déverrouillez manuellement le compte de l'utilisateur. Le verrouillage temporaire, en revanche, dissuade le bruteforcing, mais comme le scénario que vous avez mentionné, il peut verrouiller un utilisateur authentique.

N'oubliez pas 2FA!
Aussi "modèles de connexion".Si une personne se connecte systématiquement à partir du ou des mêmes emplacements (combinaison IP / ID de navigateur), les connexions en dehors de ce modèle doivent être traitées avec plus de prudence.De plus, les changements d'adresse IP avec le même ID de navigateur devraient émettre un avertissement à l'utilisateur par une autre méthode de communication.
Il n'y a pas que des sites Web - les armes nucléaires sont conçues pour détruire de minuscules morceaux à l'intérieur si elles reçoivent de mauvais codes de tir, de sorte qu'elles doivent être ramenées à l'installation centrale de traitement pour être reconstruites.
CAPTCHA n'aide pas vraiment contre les bots.Je veux dire, 2 des 3 méthodes ReCAPTCHA ont déjà été vaincues (l'une d'entre elles même par les propres services de Google), et la 3e n'est qu'une question de temps.
[xkcd obligatoire] (https://xkcd.com/810/)
@chrylis Vous avez des sources d'informations intéressantes?
@tudor Yup.Méthodes valides. 2FA - L'authentification à deux facteurs augmente considérablement le risque d'accéder aux ressources même si le mot de passe peut être forcé.Bien qu'il ne puisse pas être strictement catégorisé comme un mécanisme de protection bruteforce, je pense qu'il vaut la peine de le mentionner. Nzall Vous avez raison.Une solution infaillible est loin de la réalité.Même s'ils peuvent tous parfaitement distinguer l'humain de l'ordinateur, rien ne peut battre les fermes de résolution CAPTCHA.
@Xenos http: // nucléaireweaponarchive.org / Usa / Weapons / Pal.html https://en.wikipedia.org/wiki/Permissive_Action_Link#Limited_attempts
Il y a une raison pour laquelle les administrateurs de haut niveau sont exemptés du lock-out alors qu'ils sont les principales cibles.
Un verrouillage de plus de quelques secondes n'est pas du tout nécessaire, juste assez longtemps pour décourager les tentatives de force brute.Les verrouillages peuvent être utilisés comme des attaques par déni de service.Dix secondes entre les tentatives, plus la journalisation et une alerte e-mail dans le cas de nombreuses tentatives devraient le faire.
Il existe une quatrième option: la limitation.Ceci est techniquement similaire au verrouillage temporaire, mais avec une durée très courte pour le premier échec, puis de plus en plus longue pour les échecs suivants.
Skynet
2017-04-05 20:52:56 UTC
view on stackexchange narkive permalink

Oui, certains sites Web le font pour empêcher les attaques par force brute ou par estimation de mot de passe. Au lieu d'interdire l'utilisateur, le site Web devrait interdire à l'adresse IP d'accéder au site Web.

Si l'attaquant saute d'une adresse IP à une autre et effectue l'attaque par force brute, alors dans ce cas, le site Web peut interdire l'identifiant de l'utilisateur et informer l'utilisateur banni par e-mail ou d'une autre manière ou peut être bannir l'utilisateur pour une courte durée fera également le nécessaire.

Un espace IP pratiquement infini est disponible pour tout utilisateur final dans IPv6.
@curiousguy est-il facile pour moi d'obtenir une nouvelle adresse IPv6?Si l'attaquant ne fait que DDoSing un compte, il ne dispose pas d'une masse d'ordinateurs dans un botnet.
En IPv6, il serait suffisamment sûr pour interdire (temporairement) un / 64 offensant sans trop de risque d'affecter les autres utilisateurs.
Habituellement, l'ordinateur peut utiliser 1.8E19 différentes adresses IPv6 sans aucun effort.
@curiousguy Vous dites cela, mais comment pourrait-on facilement obtenir de nouvelles adresses de leur FAI?
@LegionMammal978 Vous n'avez pas besoin d'obtenir ces adresses auprès du FAI car le FAI vous attribue généralement un bloc entier / 64.
oui mais comme l'a souligné @FooBar vous n'interdisez pas la seule adresse IPv6 mais le réseau / 64.
Les entreprises, les écoles, etc. partagent un / 64 ou parfois un / 48.Un gars ne se souvient pas quel mot de passe il a utilisé et vous allez verrouiller toute une société?
@KarlBielefeldt Empêcher toute la société d'essayer de se connecter au compte d'un seul gars?Heck ouais, ce gars devrait être le seul sur le réseau à essayer.
@KarlBielefeldt, ce n'est pas plus que ce qui se fait couramment aujourd'hui.
@LegionMammal978 "_Comment pourrait-on facilement obtenir de nouvelles adresses auprès de leur FAI_" Ce n'est * pas * comment IPv6 fonctionne.Toute une gamme d'adresses, définie par son préfixe en binaire, est attribuée à votre routeur;au moins une plage / 64 (un préfixe d'adresse binaire de 64 bits), soit 1,8E19 adresses distinctes, et bien souvent une plage / 48 (adresses 1E24) est attribuée au routeur d'un client.Le box est responsable de la gestion de la gamme.Soit les clients utilisent DHCPv6 pour demander des adresses, soit ils utilisent la configuration automatique des adresses IPv6, dans l'esprit du protocole / APIPA Rendezvous (ou Bonjour) d'Apple.
@curiousguy D'accord, je suppose qu'il n'y a pas une telle pénurie d'adresses IPv6 que d'adresses IPv4
user2428118
2017-04-07 00:50:40 UTC
view on stackexchange narkive permalink

D'autres répondants ont déjà proposé des moyens précieux par lesquels un site Web peut empêcher l'abus de mesures anti-devinettes de mot de passe pour verrouiller les gens. En voici une autre: la liste blanche d'adresses IP.

@Skynet suggérait déjà la mise sur liste noire, mais les attaquants étant aujourd'hui capables de créer des botnets plus d'un million d'appareils en taille, ce n'est peut-être pas très efficace contre un attaquant débrouillard. (Notez qu'un attaquant n'aurait pas nécessairement besoin de créer un tel botnet lui-même: de nombreux cybercriminels louent l'accès à leurs robots.)

Donc, alors que la liste noire pourrait offrir une défense contre un attaquant moins puissant, en cas d'attaque s'adapte à un grand nombre d'adresses IP, une alternative serait d'essayer de restreindre l'accès aux adresses IP qui ont déjà été utilisées pour se connecter avec succès au compte.

Bien sûr, il faut encore faire attention pris: si un attaquant a accès à un appareil qui utilise une adresse IP en liste blanche, un site Web doit vérifier que cela ne permettra pas à l'attaquant d'échapper à la détection par force brute. De plus, comme un utilisateur peut avoir une adresse IP dynamique ou pour une autre raison, essayer de se connecter à partir d'une nouvelle adresse IP, il doit y avoir un autre mécanisme par lequel l'utilisateur peut contourner le blocage de connexion, tel que :

  • En entrant un CAPTCHA (mais soyez averti: un attaquant déterminé pourrait embaucher des personnes pour les résoudre à un prix étonnamment bas);
  • En cliquant sur un lien dans un e-mail (vous voudrez également intégrer des vérifications pour éviter que cela ne soit abusé pour inonder les boîtes de réception des gens); ou
  • Utiliser une sorte d ' authentification à deux facteurs pour prouver qu'il est le propriétaire légitime du compte.
Alesana
2017-04-08 04:05:13 UTC
view on stackexchange narkive permalink

Oui et cela a déjà été fait. Cela peut poser un gros problème avec certains sites Web. OWASP répertorie quelques exemples de problèmes pouvant survenir sur leur page sur le blocage des attaques par force brute...

Le verrouillage de compte est parfois efficace, mais uniquement dans des environnements contrôlés ou dans les cas où le risque est si grand que même des attaques DoS continues sont préférables à un compromis. Dans la plupart des cas, cependant, le verrouillage de compte est insuffisant pour arrêter les attaques par force brute. Prenons l'exemple d'un site d'enchères sur lequel plusieurs enchérisseurs se disputent le même article. Si le site Web d'enchères imposait des verrouillages de compte, un enchérisseur pouvait simplement verrouiller les comptes des autres à la dernière minute de l'enchère, les empêchant de soumettre des offres gagnantes. Un attaquant pourrait utiliser la même technique pour bloquer les transactions financières critiques ou les communications par e-mail.

Tom
2017-04-06 16:30:17 UTC
view on stackexchange narkive permalink

Oui, c'est une menace réelle et doit être pris en compte lorsque vous construisez vos défenses par force brute. Ces types d'attaques ont également été menés, ce n'est donc pas purement théorique.

De nos jours, un système fournit généralement à un utilisateur verrouillé des moyens de réinitialiser son compte, généralement via un canal séparé (courrier, SMS, etc.)

Mr. E
2017-04-05 20:53:13 UTC
view on stackexchange narkive permalink

Oui, c'est possible. Mais cela peut être évité en utilisant CAPTCHA, si le formulaire de connexion l'a, le seul moyen d'y parvenir serait de saisir manuellement des mots de passe incorrects et constitue un risque mineur. L'attaquant doit être vraiment fou pour passer toute sa journée à verrouiller votre compte

De plus, vous ne devez indiquer que le compte est verrouillé lorsque l'utilisateur entre correctement ses informations d'identification pour empêcher l'énumération du compte et ne jamais distinguer quand l'attaquant entre le mauvais mot de passe ou si l'utilisateur n'existe pas

Selon le site Web, il peut ne pas nécessiter un attaquant fou, mais un attaquant plus déterminé (les sites Web de la Maison Blanche et du gouvernement seraient très vulnérables à ces attaquants 24/7).Les sites Web de base de tous les jours ne le font probablement pas.
Huh, si vous dites qu'il est verrouillé uniquement lorsque vous trouvez les bonnes informations d'identification, alors cela semble très vulnérable: je peux continuer à forcer un compte verrouillé à connaître le mot de passe, et une fois trouvé, attendez qu'il soit déverrouillé.
Vous n'avez même pas besoin de révéler que le compte est verrouillé - envoyez simplement un seul e-mail au titulaire du compte et continuez à utiliser le message normal "Informations d'identification incorrectes" pour chaque tentative.
Des attaquants fous et des grille-pain aux portes dérobées.C'est un nouveau monde courageux, les gens!
@Xenos: L'approche habituelle pour ne révéler que le verrouillage du mot de passe correct est de révéler à l'utilisateur correct que le protocole de sécurité a été activé et qu'il doit prendre des mesures.En règle générale, une partie de la procédure de déverrouillage consiste à définir un nouveau mot de passe (revérifier efficacement par e-mail, comme dans un scénario de «mot de passe oublié») - cela atténue l’acquisition de connaissances par l’attaquant via le forçage brutal (si le message verrouillé est affiché sur la page).En attendant, un scénario beaucoup plus probable est que l'attaquant abandonne ou perd du temps sur l'attaque en prenant des actions inutiles.
@NeilSlater Si le compte est verrouillé, vous ne pouvez pas être le "bon utilisateur".Vous ne devez donc * pas * dire à celui qui veut se connecter que le compte est verrouillé.Vous * pouvez * notifier l'e-mail lié au compte qu'il est maintenant verrouillé pendant un certain temps (mais peut être utilisé pour transformer votre serveur en un SPAM).Vous * ne devriez * pas demander à cet e-mail de changer leur mot de passe (opportunités de phising).
@Xenos: Bien sûr, vous pouvez être le bon utilisateur, ou du moins l'utilisateur autorisé d'origine, en vous connectant simplement comme d'habitude et ne faisant pas partie d'une attaque simultanée - au cas où nous entrerions dans des différences de terminologie.Informer que l'utilisateur est une tâche délicate, l'e-mail n'est pas un canal de retour fiable, donc une invite sur ce qui aurait été une connexion réussie, indiquant à l'utilisateur le processus correct pour déverrouiller le compte, ce qui devrait nécessiter une authentification supplémentaire (2fa, vérification de l'e-mailetc).Si le courrier électronique était un canal fiable, facile et immédiat, les connexions pouvaient d'abord passer par courrier électronique.
Clarification: Par «non fiable», j'entends «pas en temps opportun et connu pour être disponible pour l'utilisateur au moment où il en a besoin».L'utilisateur que vous essayez de protéger peut raisonnablement s'attendre à utiliser le site normalement.Si cela ne fonctionne pas, ils ont besoin d'une explication.Ils * pourraient * avoir vu l'e-mail les informant d'un lock-out sur leur compte.Peut-être pas.Vous devez trouver un équilibre entre la réduction de la confusion de cet utilisateur et le risque de permettre à une recherche par force brute de se terminer avec succès (ce qui, lorsqu'il est effectué à distance sur Internet et probablement limité, n'est qu'un risque élevé lorsque le mot de passe est faible).
L'attaquant n'a pas besoin de passer toute sa journée à verrouiller le compte.S'il s'agit simplement d'essayer de se connecter trois fois toutes les quinze minutes pendant une journée, il y a beaucoup de gens dans le monde qui le feraient pour le prix d'un sandwich et d'un latte dans un pays du premier monde.
@NeilSlater Pour moi, il semble que vous ne comprenez pas que le serveur ne peut pas dire si l'utilisateur connecté est le légitime (celui qui dit "compte verrouillé") ou l'attaquant qui parvient à deviner le mot de passe.Un compte verrouillé est un compte auquel vous ne pouvez plus * vous connecter *, que vous ayez ou non le bon mot de passe.Je vais m'arrêter là (pour éviter de salir les commentaires).Demandez aux gens sur tchat de vous expliquer.


ⓘ
Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...