Empêcher les connexions brutes sur les sites Web

En réponse aux récents détournements de Twitter et à la publication de Jeff sur Dictionary Attacks , quel est le meilleur moyen de sécuriser votre site Web contre les attaques par connexion brutale?

Le post de Jeff suggère d’introduire un délai croissant pour chaque tentative de connexion, et une suggestion dans les commentaires est d’append un captcha après la deuxième tentative ratée.

Les deux semblent être de bonnes idées, mais comment savez-vous quel est le “numéro de tentative”? Vous ne pouvez pas compter sur un identifiant de session (car un attaquant pourrait le modifier à chaque fois) ou une adresse IP (meilleure, mais vulnérable aux botnets). Le simple fait de le consigner avec le nom d’utilisateur pourrait, en utilisant la méthode du délai, verrouiller un utilisateur légitime (ou du moins rendre le processus de connexion très lent pour eux).

Pensées? Suggestions?

    Je pense que la courte période de locking persistante de la firebase database pour le compte donné (1 à 5 minutes) est la seule façon de gérer cela. Chaque userid de votre firebase database contient un timeOfLastFailedLogin et un numberOfFailedAttempts . Lorsque numbeOfFailedAttempts > X vous verrouillez pendant quelques minutes.

    Cela signifie que vous bloquez l’ userid en question pendant un certain temps, mais pas de manière permanente. Cela signifie également que vous mettez à jour la firebase database pour chaque tentative de connexion (sauf si elle est bien sûr verrouillée), ce qui peut entraîner d’autres problèmes.

    Il y a au moins un pays entier qui est NAT en Asie, donc les adresses IP ne peuvent être utilisées pour rien.

    A mes yeux, il y a plusieurs possibilités, chacune ayant des avantages et des inconvénients:

    Forcer les mots de passe sécurisés

    • Pro : prévient les attaques par dictionnaire
    • Con : va également empêcher la popularité, car la plupart des utilisateurs ne sont pas en mesure de se souvenir des mots de passe complexes, même si vous leur expliquez comment se souvenir d’eux facilement. Par exemple, en se rappelant des phrases: “J’ai acheté 1 Apple pour 5 centimes dans le centre commercial” conduit à “Ib1Af5CitM”.

    Lockouts après plusieurs tentatives

    • Pro : ralentira les tests automatisés
    • Con : Il est facile de verrouiller les utilisateurs pour des tiers
    • Con : Les rendre persistants dans une firebase database peut entraîner de nombreux processus d’écriture dans des services aussi importants que Twitter ou comparables.

    Captchas

    • Pro : ils empêchent les tests automatisés
    • Con : Ils consumnt du temps de calcul
    • Con : va “ralentir” l’expérience utilisateur
    • HUGE CON : Ils ne sont pas sans obstacle

    Contrôles de connaissances simples

    • Pro : empêchera les tests automatisés
    • Con : “Simple” est dans l’oeil du spectateur.
    • Con : va “ralentir” l’expérience utilisateur

    Identifiant et nom d’utilisateur différents

    • Pro : C’est une technique que l’on voit à peine, mais à mes yeux, un bon départ pour prévenir les attaques par force brute.
    • Con : Dépend du choix des utilisateurs des deux noms.

    Utiliser des phrases entières comme mots de passe

    • Pro : augmente la taille de l’espace de recherche disponible.
    • Pro : plus facile à retenir pour la plupart des utilisateurs.
    • Con : dépend du choix des utilisateurs.

    Comme vous pouvez le constater, les “bonnes” solutions dépendent toutes du choix des utilisateurs, ce qui révèle à nouveau que l’utilisateur est l’élément le plus faible de la chaîne.

    D’autres suggestions?

    Vous pouvez faire ce que fait Google. Ce qui fait qu’après un certain nombre de trys, ils ont un captacha. Après quelques minutes avec la captacha, vous les verrouillez pendant quelques minutes.

    J’ai tendance à être d’accord avec la plupart des autres commentaires:

    • Verrouiller après X échec des tentatives de mot de passe
    • Nombre de tentatives infructueuses contre le nom d’utilisateur
    • Utiliser éventuellement CAPTCHA (par exemple, les tentatives 1-2 sont normales, les tentatives 3-5 sont CAPTCHA, les tentatives supplémentaires bloquées pendant 15 minutes).
    • Envoyer éventuellement un courrier électronique au propriétaire du compte pour supprimer le bloc

    Ce que je voulais souligner, c’est que vous devez faire très attention à forcer les mots de passe “forts”, car cela signifie souvent qu’ils seront simplement écrits sur un post-it sur le bureau / attaché au moniteur. En outre, certaines stratégies de mot de passe conduisent à des mots de passe plus prévisibles. Par exemple:

    Si le mot de passe ne peut pas être un mot de passe précédemment utilisé et doit contenir un numéro, il y a de fortes chances que ce soit un mot de passe commun avec un numéro séquentiel. Si vous devez changer votre mot de passe tous les six mois et qu’une personne y a passé deux ans, il est probable que son mot de passe est quelque chose comme password4 .

    Disons que vous le restreignez encore plus: il doit contenir au moins 8 caractères, ne doit pas avoir de lettres séquentielles, doit avoir une lettre, un chiffre et un caractère spécial (il s’agit d’une véritable politique de mot de passe que beaucoup considèrent sécurisée). Essayer de pénétrer dans le compte de John Quincy Smith? Savoir qu’il est né le 6 mars? Il y a de bonnes chances que son mot de passe soit quelque chose comme jqs0306! (ou peut-être jqs0306 ~ ).

    Maintenant, je ne dis pas que laisser à vos utilisateurs le mot de passe mot de passe est une bonne idée non plus, mais ne vous laissez pas persuader que vos mots de passe “sécurisés” forcés sont sécurisés.

    Elaborer les meilleures pratiques:

    Ce que krosenvold a dit: connectez num_failed_logins et last_failed_time dans la table utilisateur (sauf lorsque l’utilisateur est suspendu), et une fois que le nombre de connexions échouées atteint un seuil, vous suspendez l’utilisateur pendant 30 secondes ou une minute. C’est la meilleure pratique.

    Cette méthode élimine efficacement les attaques par brute-force et les attaques par dictionnaire. Cependant, cela n’empêche pas un attaquant de passer d’un nom d’utilisateur à l’autre – c.-à-d. en gardant le mot de passe fixe et en l’essayant avec un grand nombre de noms d’utilisateur. Si votre site a suffisamment d’utilisateurs, ce type d’attaque peut durer longtemps avant qu’il ne soit à court de comptes non suspendus. Avec un peu de chance, il lancera cette attaque à partir d’une seule adresse IP (ce qui est peu probable car les réseaux de zombies sont en train de devenir l’outil du commerce). Vous pouvez donc détecter cela et bloquer l’adresse IP . Eh bien, c’est une autre question (que je viens de poster ici, alors s’il vous plait, vérifiez-la si vous ne l’avez pas fait) .

    Une chose supplémentaire à retenir à propos de l’idée originale est que vous devriez toujours essayer de laisser l’utilisateur légitime, même lorsque le compte est attaqué et suspendu – c’est-à-dire si vous pouvez distinguer l’utilisateur réel et le bot.

    Et vous POUVEZ, de deux manières au moins.

    1. Si l’utilisateur dispose d’un cookie de connexion persistante (“Remember Me”), laissez-le passer.

    2. Lorsque vous affichez le message “Je suis désolé, votre compte est suspendu en raison d’un grand nombre de tentatives de connexion infructueuses”, incluez un lien indiquant ” Connexion sécurisée à la sauvegarde – HUMAINS UNIQUEMENT (bots: non couché) “. Blague à part, quand ils cliquent sur ce lien, donnez-leur un formulaire de connexion authentifié reCAPTCHA qui contourne le statut de suspension du compte. De cette façon, s’ils sont humains ET connaissent le bon login + mot de passe (et sont capables de lire CAPTCHA), ils ne seront jamais dérangés par des retards et votre site sera insensible aux attaques rapides.

    Seul inconvénient: certaines personnes (telles que les malvoyants) ne peuvent pas lire les CAPTCHA, et elles PEUVENT toujours être affectées par des retards gênants si elles n’utilisent pas la fonctionnalité de connexion automatique.

    Ce qui n’est pas un inconvénient: le cookie d’authentification automatique ne comporte pas de mesure de sécurité similaire intégrée. Pourquoi n’est-ce pas un inconvénient, vous demandez? Parce que tant que vous l’avez implémenté avec sagesse, le jeton sécurisé (le mot de passe équivalent) de votre cookie de connexion est deux fois plus nombreux (heck, faites-en dix fois plus de bits!) Que votre mot de passe. effectivement un non-problème . Mais si vous êtes vraiment paranoïaque, installez un délai d’une seconde sur la fonction de connexion automatique, juste pour faire bonne mesure.

    Faites comme la plupart des banques, verrouillez le nom d’utilisateur / compte après X échecs de connexion. Mais je ne serais pas aussi ssortingct qu’une banque dans laquelle vous devez appeler pour débloquer votre compte. Je ferais juste un locking temporaire de 1 à 5 minutes. Bien sûr, l’application Web est aussi sensible aux données qu’une banque. 🙂

    Vous devez implémenter un cache dans l’application non associée à votre firebase database principale à cette fin.

    Tout d’abord, le fait de ne reporter que les noms d’utilisateur légitimes vous amène à “abandonner” votre base de clients valide, ce qui peut poser problème même si le nom d’utilisateur n’est pas un secret bien gardé.

    Deuxièmement, en fonction de votre application, vous pouvez être un peu plus intelligent avec des contre-mesures de délai spécifiques à l’application que vous ne le souhaiteriez pour stocker les données dans une firebase database.

    Il est résistant aux tentatives à grande vitesse qui pourraient provoquer une fuite de DOS dans votre firebase database.

    Enfin, il est acceptable de prendre certaines décisions en fonction de la propriété intellectuelle … Si vous constatez qu’une seule tentative d’une adresse IP est une erreur par rapport à plusieurs adresses IP, vous savez combien de systèmes vous pouvez prendre ou avertir l’utilisateur final. activité louche.

    Ses véritables fédérations de proxy peuvent avoir un nombre important d’adresses IP réservées pour leur utilisation, mais la plupart font des efforts raisonnables pour conserver votre adresse source pendant une période donnée, car certains sites ont la capacité de lier les données de cookie à IP.

    Je pense que vous devriez vous connecter au nom d’utilisateur. C’est la seule constante (tout le rest peut être falsifié). Et oui, il pourrait bloquer un utilisateur légitime pour une journée. Mais si je dois choisir entre un compte piraté et un compte fermé (pour un jour), j’ai définitivement choisi le verrou.

    Au fait, après une troisième tentative infructueuse (dans un certain délai), vous pouvez verrouiller le compte et envoyer un courrier de libération au propriétaire. Le courrier contient un lien pour déverrouiller le compte. C’est un léger fardeau pour l’utilisateur mais le cracker est bloqué. Et si même le compte de messagerie est piraté, vous pouvez définir une limite au nombre de déblocages par jour.

    Un grand nombre de forums de discussion en ligne auxquels je me connecte en ligne me donnent 5 tentatives de connexion à un compte. Après ces 5 tentatives, le compte est verrouillé pendant une heure ou quinze minutes. Ce n’est peut-être pas joli, mais cela ralentirait certainement une attaque par dictionnaire sur un compte. Maintenant, rien n’arrête une attaque de dictionnaire contre plusieurs comptes en même temps. Ie essayer 5 fois, passer à un autre compte, essayer 5 fois de plus, puis reculer. Mais cela ralentit certainement l’attaque.

    La meilleure défense contre une attaque par dictionnaire est de s’assurer que les mots de passe ne sont pas dans un dictionnaire !!! Configurez essentiellement une sorte de stratégie de mot de passe qui vérifie un dictionnaire par rapport aux lettres et requirejs un numéro ou un symbole dans le mot de passe. C’est probablement la meilleure défense contre une attaque par dictionnaire.

    Vous pouvez append une forme de test CAPTCHA. Mais attention, la plupart d’entre eux rendent l’access plus difficile aux yeux ou aux personnes à mobilité réduite. Une forme intéressante de CAPTCHA pose une question,

    Quelle est la sum de 2 et 2?

    Et si vous enregistrez le dernier échec de connexion, vous pouvez ignorer le CAPTCHA s’il est suffisamment ancien. Ne faites le test CAPTCHA que si le dernier échec a eu lieu au cours des 10 dernières minutes.

    Ceci est un ancien message. Cependant, j’ai pensé à mettre mes découvertes ici pour que cela puisse aider tout futur développeur.

    Nous devons empêcher les attaques par force brute afin que l’attaquant ne puisse pas récupérer le nom d’utilisateur et le mot de passe d’une connexion au site Web. Dans de nombreux systèmes, ils ont des URL ouvertes qui ne nécessitent pas de jeton d’authentification ou de clé API pour l’autorisation. La plupart de ces API sont critiques. Par exemple; Les API d’inscription, de connexion et d’oubli de mot de passe sont souvent ouvertes (c.-à-d. Qu’elles ne nécessitent pas de validation du jeton d’authentification). Nous devons nous assurer que les services ne sont pas abusés. Comme indiqué précédemment, je ne fais que présenter mes constatations tout en étudiant comment nous pouvons prévenir efficacement une attaque par force brute.

    La plupart des techniques de prévention courantes sont déjà abordées dans cet article. Je voudrais append mes préoccupations concernant le locking de compte et le locking d’adresse IP. Je pense que le locking des comptes est une mauvaise idée en tant que technique de prévention. Je mets quelques points ici pour soutenir ma cause.

    Le locking de compte est mauvais

    • Un attaquant peut provoquer un déni de service en bloquant un grand nombre de comptes.
    • Comme vous ne pouvez pas verrouiller un compte qui n’existe pas, seuls les noms de compte valides seront verrouillés. Un attaquant pourrait utiliser ce fait pour collecter des noms d’utilisateurs sur le site, en fonction des réponses d’erreur.
    • Un attaquant peut provoquer un détournement en verrouillant de nombreux comptes et en inondant le support technique d’appels de support.
    • Un attaquant peut toujours verrouiller le même compte, même quelques secondes après que l’administrateur l’a débloqué, désactivant ainsi le compte.
    • Le locking de compte est inefficace contre les attaques lentes qui n’essayent que quelques mots de passe toutes les heures.
    • Le locking de compte est inefficace contre les attaques qui essaient un seul mot de passe par rapport à une grande liste de noms d’utilisateur.
    • Le locking de compte est inefficace si l’attaquant utilise une liste déroulante de nom d’utilisateur / mot de passe et devine correctement lors des deux premières tentatives.
    • Les comptes puissants, tels que les comptes d’administrateur, contournent souvent la politique de locking, mais ce sont les comptes les plus souhaitables à attaquer. Certains systèmes bloquent les comptes d’administrateur uniquement sur les connexions réseau.
    • Même une fois que vous verrouillez un compte, l’attaque peut continuer, consommant des ressources humaines et informatiques de grande valeur.
    • Considérons, par exemple, 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 lockings de compte, un enchérisseur pouvait simplement verrouiller les comptes des autres dans 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 des transactions financières critiques ou des communications par courrier électronique.

    Le locking d’adresse IP pour un compte est également une mauvaise idée

    Une autre solution consiste à verrouiller une adresse IP avec plusieurs connexions échouées. Le problème avec cette solution est que vous pouvez bloquer par inadvertance de grands groupes d’utilisateurs en bloquant un serveur proxy utilisé par un fournisseur de services Internet ou une grande entreprise. Un autre problème est que de nombreux outils utilisent des listes de proxy et n’envoient que quelques requêtes de chaque adresse IP avant de passer à la suivante. En utilisant des listes de proxy ouvertes largement disponibles sur des sites tels que http://tools.rosinstrument.com/proxy/ , un attaquant pourrait facilement contourner tout mécanisme de blocage IP. Comme la plupart des sites ne bloquent pas après un seul mot de passe ayant échoué, un attaquant peut utiliser deux ou trois tentatives par proxy. Un attaquant avec une liste de 1 000 proxys peut tenter 2 000 ou 3 000 mots de passe sans être bloqué. Néanmoins, malgré les faiblesses de cette méthode, les sites Web qui connaissent un grand nombre d’attaques, en particulier les sites Web pour adultes, choisissent de bloquer les adresses IP proxy.

    Ma proposition

    • Ne pas verrouiller le compte. Au lieu de cela, nous pourrions envisager d’append un délai intentionnel côté serveur dans les tentatives de connexion / d’inscription pour de fausses tentatives consécutives.
    • Suivi de l’emplacement de l’utilisateur en fonction de l’adresse IP lors des tentatives de connexion, une technique couramment utilisée par Google et Facebook. Google envoie un OTP tandis que Facebook fournit d’autres défis de sécurité, tels que la détection des amis de l’utilisateur à partir des photos.
    • Re-captcha de Google pour les applications Web, SafetyNet pour Android et la technique d’attestation d’applications mobiles appropriée pour iOS – dans les demandes de connexion ou d’inscription.
    • Cookie de l’appareil
    • Construire un système de surveillance des appels d’API pour détecter les appels inhabituels pour un certain sharepoint terminaison d’API.

    Propositions expliquées

    Retard intentionnel en réponse

    Le délai d’authentification par mot de passe ralentit considérablement l’attaquant, car le succès de l’attaque dépend du temps. Une solution simple consiste à injecter des pauses aléatoires lors de la vérification d’un mot de passe. L’ajout d’une pause de quelques secondes ne dérange pas la plupart des utilisateurs légitimes lorsqu’ils se connectent à leurs comptes.

    Notez que bien que l’ajout d’un délai puisse ralentir une attaque mono-thread, il est moins efficace si l’attaquant envoie plusieurs demandes d’authentification simultanées.

    Défis de sécurité

    Cette technique peut être décrite comme des défis de sécurité adaptatifs basés sur les actions effectuées par l’utilisateur lors de l’utilisation du système plus tôt. Dans le cas d’un nouvel utilisateur, cette technique peut générer des problèmes de sécurité par défaut.

    Nous pourrions envisager de mettre en place lorsque nous lancerons des défis de sécurité? Il y a plusieurs points où nous pouvons.

    • Lorsque l’utilisateur tente de se connecter depuis un emplacement où il n’était pas situé à proximité auparavant.
    • Mauvaises tentatives de connexion

    Quel type de défi de sécurité l’utilisateur pourrait-il rencontrer?

    • Si l’utilisateur définit les questions de sécurité, nous pourrions envisager de demander aux utilisateurs des réponses à ces questions.
    • Pour les applications telles que Whatsapp, Viber, etc., nous pourrions envisager de prendre des noms de contacts aléatoires dans l’annuaire téléphonique et demander de les indiquer ou inversement.
    • Pour les systèmes transactionnels, nous pourrions envisager de demander à l’utilisateur les dernières transactions et paiements.

    Panneau de surveillance API

    Pour créer un panneau de surveillance pour les appels d’API.

    • Recherchez les conditions pouvant indiquer une attaque par force brute ou un autre abus de compte dans le panneau de surveillance de l’API.
    • Beaucoup de connexions ont échoué à partir de la même adresse IP.
    • Les connexions avec plusieurs noms d’utilisateur provenant de la même adresse IP.
    • Connexions pour un seul compte provenant de nombreuses adresses IP différentes.
    • Utilisation excessive et consommation de bande passante à partir d’une utilisation unique.
    • Echec des tentatives de connexion à partir de noms d’utilisateurs ou de mots de passe séquentiels.
    • Les connexions avec des mots de passe suspects que les pirates utilisent couramment, tels que ownsyou (ownzyou), washere (wazhere), zealots, hacksyou etc.

    Pour les comptes système internes, nous pouvons envisager d’autoriser la connexion uniquement à partir de certaines adresses IP. Si le locking du compte doit être en place, au lieu de verrouiller complètement un compte, placez-le en mode verrouillé avec des capacités limitées.

    Voici quelques bonnes lectures.

    Pour l’environnement .NET

    Ressortingctions IP dynamics

    L’extension de ressortingctions IP dynamics pour IIS fournit aux professionnels de l’informatique et aux hébergeurs un module configurable qui permet d’atténuer ou de bloquer les attaques par déni de service ou le piratage des mots de passe via le blocage temporaire des adresses IP des clients HTTP qui suivent un modèle. être propice à l’une de ces attaques. Ce module peut être configuré de sorte que l’parsing et le blocage puissent être effectués au niveau du serveur Web ou du site Web.

    Réduisez les risques d’attaque par déni de service en bloquant de manière dynamic les requêtes provenant d’adresses IP malveillantes

    Les ressortingctions IP dynamics pour IIS vous permettent de réduire les probabilités que votre serveur Web soit soumis à une attaque de déni de service en inspectant l’adresse IP source des requêtes et en identifiant les modèles susceptibles de signaler une attaque. Lorsqu’un modèle d’attaque est détecté, le module place l’adresse IP incriminée dans une liste de refus temporaire et évite de répondre aux demandes pendant une durée prédéterminée.

    Minimiser les possibilités de craquage par force brute des mots de passe de votre serveur Web

    Les ressortingctions IP dynamics pour IIS peuvent détecter les modèles de demande indiquant que les mots de passe du serveur Web doivent être décodés. Le module placera l’adresse IP incriminée sur une liste de serveurs auxquels l’access est refusé pour une durée prédéterminée. Dans les cas où l’authentification est effectuée sur un Active Directory Services (ADS), le module est capable de maintenir la disponibilité du serveur Web en évitant de devoir lancer des défis d’authentification pour ADS.

    Caractéristiques

    • Intégration transparente dans le gestionnaire IIS 7.0.

    • Blocage dynamic des demandes provenant d’une adresse IP en fonction de l’un des critères suivants:

      • Le nombre de demandes simultanées.

      • Le nombre de demandes sur une période de temps.

    • Prise en charge de la liste des adresses IP autorisées à contourner le filtrage de ressortingction IP dynamic.

    • Le blocage des requêtes peut être configurable au niveau du site Web ou du serveur Web.

    • Les actions de refus configurables permettent aux administrateurs informatiques de spécifier quelle réponse serait renvoyée au client. Le module prend en charge les codes d’état de retour 403, 404 ou la fermeture de la connexion.

    • Prise en charge des adresses IPv6.

    • Prise en charge des serveurs Web derrière un proxy ou un pare-feu pouvant modifier l’adresse IP du client.

    http://www.iis.net/download/DynamicIPRessortingctions

    Ancien message, mais laissez-moi poster ce que j’ai à la fin de 2016. J’espère que cela pourrait encore aider.

    C’est un moyen simple mais je pense qu’il est puissant pour empêcher les attaques par connexion. Au moins, je l’utilise toujours sur tous les sites Web. Nous n’avons pas besoin de CAPTCHA ou d’autres plugins tiers.

    Lorsque l’utilisateur se connecte pour la première fois. Nous créons une session comme

     $_SESSION['loginFail'] = 10; // any number you prefer 

    En cas de réussite de la connexion, nous le détruirons et laisserons l’utilisateur se connecter.

     unset($_SESSION['loginFail']); // put it after create login session 

    Mais si l’utilisateur échoue, comme nous leur envoyons généralement un message d’erreur, en même temps, nous réduisons la session de 1:

     $_SESSION['loginFail']-- ; // reduce 1 for every error 

    et si l’utilisateur échoue 10 fois, nous les dirigerons vers un autre site Web ou des pages Web.

     if (!isset($_SESSION['loginFail'])) { if ($_SESSION['login_fail'] < 1 ) { header('Location:https://google.com/'); // or any web page exit(); } } 

    De cette façon, l'utilisateur ne peut plus ouvrir ou accéder à notre page de connexion, car il a été redirigé vers un autre site Web.

    Les utilisateurs doivent fermer le navigateur (pour détruire la session loginFail que nous avons créée), ouvrez-le à nouveau pour voir notre page de connexion 'à nouveau'.

    Est-ce utile?