Quelle est la meilleure contre-mesure de la force brute distribuée?

https://stackoverflow.com/questions/479233

20-08-2019
|

Question

Tout d’abord, un peu d’arrière-plan: Ce n’est un secret pour personne que j’implémente un système auth + auth pour CodeIgniter, et jusqu’à présent, je suis en train de gagner (pour ainsi dire). Mais je me suis heurté à un défi plutôt non trivial (un défi qui manque totalement à la plupart des bibliothèques d'authentification, mais j'insiste pour le gérer correctement): comment gérer intelligemment brute-force à grande échelle, distribué, à nom d'utilisateur variable attaques .

Je connais tous les trucs habituels:

Limiter le nombre de tentatives infructueuses par adresse IP / hôte et refuser l'accès au contrevenant (par exemple, Fail2Ban) - ce qui ne fonctionne plus depuis que les réseaux de zombies sont devenus plus intelligents
Combinaison de ce qui précède avec une liste noire d'adresses IP / hôtes "incorrects" (par exemple, DenyHosts) - qui repose sur les réseaux de zombies qui tombent pour # 1, ce qu'ils ne font pas de plus en plus
listes blanches IP / hôte combinées à l'authentification traditionnelle (malheureusement inutiles pour les utilisateurs IP dynamiques et le taux de désabonnement élevé sur la plupart des sites Web)
Définition d'une limite à l'échelle du site sur le nombre de tentatives infructueuses au cours d'une période de N minutes / heure et limitation (suspension) de toutes les tentatives de connexion subséquentes pendant plusieurs minutes / heures (avec le même problème vous attaquer devient un jeu d'enfant de botnet)
signatures numériques obligatoires (certificats de clé publique) ou jetons de matériel RSA pour tous les utilisateurs sans option NO de connexion / mot de passe (sans aucun doute une solution solide, mais pratique uniquement pour les services dédiés fermés)
Modèles de mots de passe ultra-forts appliqués (par exemple, > 25 caractères absurdes avec des symboles - là aussi, trop peu pratique pour les utilisateurs occasionnels)
Et enfin, CAPTCHAs (qui pourraient fonctionner dans la plupart des cas, mais sont gênants pour les utilisateurs et pratiquement inutile contre un attaquant déterminé, ingénieux )

Maintenant, ce ne sont que des idées théoriquement exploitables. Il y a beaucoup d'idées de saleté qui ouvrent grand-chose au site (par exemple, aux attaques de déni de service triviales). Ce que je veux, c'est quelque chose de mieux. Et par meilleur, je veux dire:

Il doit être sécurisé (+) contre les attaques par force brute et DoS, et ne pas introduire de nouvelles vulnérabilités qui pourraient permettre à un bot légèrement plus furtif de continuer à fonctionner sous le radar
Cela doit être automatisé. Si un opérateur humain doit vérifier chaque connexion ou surveiller une activité suspecte, cela ne fonctionnera pas dans un scénario réel
Il doit être réalisable pour une utilisation Web standard (c'est-à-dire un taux de roulement élevé, un volume élevé et un enregistrement ouvert pouvant être effectué par des non-programmeurs)
Cela ne peut pas gêner l'expérience utilisateur au point que les utilisateurs occasionnels soient ennuyés ou frustrés (et risquent éventuellement d'abandonner le site)
Cela ne concerne pas les chatons, à moins qu'ils ne soient vraiment très sécurisés chatons

(+) Par "sécurisé", j'entends au moins aussi sûr que la capacité d'un utilisateur paranoïaque à garder son mot de passe secret

Alors, écoutons! Comment le feriez-vous ? Connaissez-vous une meilleure pratique que je n'ai pas mentionnée (oh, dites-le, s'il vous plaît)? Je reconnais que j’ai une idée personnelle (combinant les idées de 3 et 4), mais je laisserai les vrais experts parler avant de me gêner; -)

La solution

D'accord, assez de ralentissement; voici ce que je suis arrivé jusqu'à présent

(désolé, poste long à venir. Soyez courageux, mon ami, le voyage en vaudra la peine)

Combinez les méthodes 3 et 4 du message d'origine dans une sorte de liste blanche "floue" ou dynamique, puis - et voici le truc - de ne pas bloquer les adresses IP non inscrites sur la liste blanche, mais de les réduire en enfer et de revenir en arrière .

Notez que cette mesure est seulement dans le but de contrecarrer ce type d'attaque très spécifique. En pratique, bien sûr, cela fonctionnerait en combinaison avec d’autres méthodes recommandées d’authentification: limitation du nom d’utilisateur fixe, limitation par adresse IP, stratégie de mot de passe renforcé, code de connexion renforcé, connexion par cookie sans entrave, hachage de tous les équivalents de mot de passe avant de les enregistrer, jamais. en utilisant des questions de sécurité, etc.

Hypothèses relatives au scénario d'attaque

Si un attaquant cible des noms d'utilisateurs variables, notre limitation de nom d'utilisateur ne se déclenche pas. Si l’attaquant utilise un réseau de zombies ou a accès à une large plage IP, notre limitation IP est sans puissance. Si l'attaquant a pré-gratté notre liste d'utilisateurs (généralement possible sur des services Web à enregistrement ouvert), nous ne pouvons pas détecter une attaque en cours basée sur le nombre d'erreurs "utilisateur non trouvé". Et si nous appliquons une limitation restrictive à l’échelle du système (tous les noms d’utilisateur, toutes les adresses IP), toute attaque de ce type créera la totalité de notre site pendant toute la durée de l’attaque, plus la période de limitation.

Nous devons donc faire autre chose.

Première partie de la contre-mesure: liste blanche

Ce dont nous pouvons être assez sûrs, c’est que l’attaquant ne peut pas détecter ni usurper de manière dynamique les adresses IP de plusieurs milliers de nos utilisateurs (+). Ce qui rend liste blanche possible. En d'autres termes: pour chaque utilisateur, nous stockons une liste des adresses IP (hachées) à partir desquelles l'utilisateur s'est connecté (récemment).

Ainsi, notre système de liste blanche fonctionnera comme une "porte d'entrée" verrouillée, dans laquelle un utilisateur doit être connecté à partir de l'une de ses "bonnes" adresses IP pour pouvoir se connecter. Une attaque par force brute sur cette porte serait pratiquement impossible (+).

(+) à moins que l'attaquant ne "possède" le serveur, toutes les boîtes de nos utilisateurs ou la connexion elle-même - et dans ce cas, nous n'avons plus de problème d'authentification, nous avons une véritable taille de franchise situation FUBAR à débrancher

Deuxième partie de la contre-mesure: limitation de l'ensemble du système des adresses IP non reconnues

Pour que la liste blanche fonctionne pour un service Web à enregistrement ouvert, où les utilisateurs changent fréquemment d'ordinateurs et / ou se connectent à partir d'adresses IP dynamiques, nous devons garder une «porte cat.» ouverte pour les utilisateurs se connectant à partir d'adresses IP non reconnues. L'astuce consiste à concevoir cette porte de manière à ce que les réseaux de zombies restent bloqués, de sorte que les utilisateurs légitimes se fassent déranger le moins possible .

Dans mon schéma, ceci est obtenu en définissant un nombre maximal très restrictif de tentatives de connexion infructueuses par des adresses IP non approuvées sur une période de 3 heures (par exemple, il est peut-être plus judicieux période plus longue en fonction du type de service) et en rendant cette restriction globale , c'est-à-dire. pour tous les comptes d'utilisateurs.

Même une force brute lente (1-2 minutes entre les tentatives) serait détectée et contrecarrée rapidement et efficacement en utilisant cette méthode. Bien sûr, une force vraiment lente pourrait rester inaperçue, mais des vitesses trop faibles vont à l'encontre du but même de l'attaque par force brute.

Ce que je souhaite accomplir avec ce mécanisme de limitation, c’est que si la limite maximale est atteinte, notre "porte chat" se ferme pendant un moment, mais notre porte principale reste ouverte aux utilisateurs légitimes qui se connectent par les moyens habituels:

soit en se connectant à partir de l'une de leurs adresses IP reconnues
Ou en utilisant un cookie de connexion persistant (de n'importe où)

Les seuls utilisateurs légitimes qui seraient affectés lors d'une attaque - c'est-à-dire. whSi la limitation était activée, il s'agirait d'utilisateurs sans cookies de connexion persistants qui se connectaient depuis un emplacement inconnu ou avec une adresse IP dynamique. Ces utilisateurs ne pourraient pas se connecter avant la fin de la limitation (ce qui pourrait éventuellement prendre un certain temps si l'attaquant maintenait son réseau de robots en marche malgré la limitation).

Pour permettre à ce petit sous-groupe d'utilisateurs de se faufiler à travers la porte du chat autrement scellée, même si les robots le bousculaient encore, j'utilisais un formulaire de connexion «de secours» avec un CAPTCHA. Ainsi, lorsque vous affichez le & Quot; Désolé, mais vous ne pouvez pas vous connecter à partir de cette adresse IP pour le moment & Quot; un message contenant un lien indiquant & "; connexion à la sauvegarde sécurisée - HUMAINS UNIQUEMENT ( bots: ne mentez pas ) &"; Blague à part, quand ils cliquent sur ce lien, donnez-leur un formulaire de connexion authentifié par reCAPTCHA qui contourne la limitation à l'échelle du site. De cette façon, s’ils sont humains ET connaissent le nom d'utilisateur et le mot de passe corrects (et sont capables de lire les CAPTCHA), le service leur sera jamais , même s'ils se connectent à partir d'un hôte inconnu et n'utilisent pas le cookie de connexion automatique.

Oh, et juste pour clarifier: étant donné que je considère que les CAPTCHA sont généralement diaboliques, l'option de connexion "de sauvegarde" n'apparaît que lorsque le contrôle est activé .

On ne peut nier qu’une telle attaque continue constituerait toujours une forme d’attaque DoS, mais avec le système décrit en place, cela ne concernerait que ce que je soupçonne d’être un minuscule sous-ensemble d’utilisateurs, à savoir les personnes qui ne le font pas. ne pas utiliser le & "Souvenez-vous de moi &"; cookie ET se connecte alors qu’une attaque est en cours ET ne se connecte à partir d’aucune de ses adresses IP habituelles ET qui ne peuvent pas lire les CAPTCHA. Seuls ceux qui peuvent dire non à TOUS ces critères - en particulier les bots et les malchanceux personnes handicapées - seront refusés lors d’une attaque par bot.

ÉDITER: En fait, j'ai pensé à un moyen de laisser passer même les utilisateurs interpellés par CAPTCHA lors d'un "verrouillage": au lieu de, ou en tant que En plus de, la connexion de secours CAPTCHA, donne à l’utilisateur la possibilité d’envoyer à son courrier électronique un code de verrouillage à usage unique et spécifique à l’utilisateur, qu’il pourra ensuite utiliser pour contourner la limitation. Cela dépasse certainement mon seuil d '"ennui", mais comme il n'est utilisé qu'en tant que dernier recours pour un petit groupe d'utilisateurs, et qu'il vaut toujours mieux que votre compte soit verrouillé, il serait acceptable.

(Notez également que aucun ne survient si l'attaque est moins sophistiquée que la version distribuée désagréable que j'ai décrite ici. Si l'attaque provient de quelques adresses IP ou ne frappe que quelques noms d'utilisateurs, il sera déjoué beaucoup plus tôt et avec pas conséquences sur l'ensemble du site)

Voilà donc la contre-mesure que je vais mettre en place dans ma bibliothèque d'authentification, une fois que je suis convaincu que le son est bon et qu'il n'y a pas de solution beaucoup plus simple que j'ai ratée. Le fait est qu'il existe de nombreuses façons subtiles de faire des erreurs en matière de sécurité, et je ne suis pas au-dessus de ce que je fais de fausses hypothèses ou de logique désespérément imparfaite. Alors, s'il vous plaît, tous les commentaires, critiques et améliorations, subtilités, etc. sont très appréciés.

Autres conseils

Quelques étapes simples:

Faites une liste noire de certains noms d’utilisateurs courants et utilisez-les comme pot de miel. Administrateur, invité, etc. ... Ne laissez personne créer des comptes avec ces noms. Si quelqu'un essaie de les connecter, vous savez que quelqu'un fait quelque chose qu'il ne devrait pas.

Assurez-vous que toute personne disposant d'un véritable pouvoir sur le site dispose d'un mot de passe sécurisé. Exigez que les administrateurs / modérateurs aient des mots de passe plus longs composés d’un mélange de lettres, de chiffres et de symboles. Rejetez des mots de passe trivialement simples d'utilisateurs habituels avec une explication.

Une des choses les plus simples que vous puissiez faire est d'informer les personnes qui tentent de se connecter à leur compte et de leur donner un lien leur permettant de signaler l'incident s'il ne s'agissait pas d'eux. Un simple message quand ils se connectent, comme & "Quelqu'un a tenté de se connecter à votre compte à 04h20 mercredi, bla bla. Cliquez ici si ce n'était pas vous. & Quot; Il vous permet de conserver des statistiques sur les attaques. Vous pouvez renforcer la surveillance et les mesures de sécurité si vous constatez une augmentation soudaine des accès frauduleux.

Si je comprends bien le mode d’action des attaques par force brute, un ou plusieurs noms d’utilisateur sont essayés en permanence.

Il y a deux suggestions que je ne pense pas avoir encore vues ici:

J'ai toujours pensé que la pratique habituelle consistait à avoir un court délai (environ une seconde) après chaque erreur de connexion pour chaque utilisateur. Cela dissuade la force brute, mais je ne sais pas combien de temps un délai d'une seconde empêcherait une attaque par dictionnaire. (Dictionnaire de 10.000 mots == 10.000 secondes == environ 3 heures. Hmm. Pas assez bon.)
au lieu d’un ralentissement à l’échelle du site, pourquoi pas une limitation du nom d’utilisateur. La manette devient de plus en plus dure à chaque tentative erronée (jusqu’à une limite, je suppose donc que le véritable utilisateur peut toujours se connecter)

Modifier : En réponse aux commentaires sur un identifiant throttle: il s’agit d’un étranglement spécifique à un nom d'utilisateur, indépendamment de la source de l'attaque.

Si le nom d'utilisateur est limité, même une attaque coordonnée de nom d'utilisateur (adresse IP unique, estimation unique par adresse IP, même nom d'utilisateur) serait interceptée. Les noms d'utilisateurs individuels sont protégés par la commande des gaz, même si les attaquants sont libres d'essayer un autre utilisateur / passe pendant le délai d'attente.

Du point de vue des attaquants, vous pourrez peut-être, pour la première fois, deviner 100 mots de passe et découvrir rapidement un mot de passe incorrect par compte. Vous ne pourrez peut-être faire que 50 secondes pour la même période.

Du point de vue du compte utilisateur, il faut toujours le même nombre moyen de suppositions pour casser le mot de passe, même si les suppositions proviennent de sources multiples.

Pour les attaquants, au mieux, ce sera le même effort pour casser 100 comptes qu’un compte, mais comme vous n’étouffez pas sur l’ensemble du site, vous pouvez accélérer assez rapidement.

Raffinements supplémentaires:

détecter les IP qui tentent de deviner plusieurs comptes - Délai d'attente de la requête 408
détecte les adresses IP qui tentent de deviner le même compte - Délai d'expiration de la requête 408 après un grand nombre (par exemple, 100) de suppositions.

Idées d’interface utilisateur (peut ne pas convenir dans ce contexte), qui peuvent également préciser ce qui précède:

si vous maîtrisez le paramètre de mot de passe, affichez ensuite l'utilisateur la force de leur mot de passe les encourage à en choisir un meilleur.
si vous avez le contrôle de la page de connexion , après un petit nombre (par exemple, 10) de réponses à un seul nom d'utilisateur, proposez un CAPTCHA.

Il existe trois facteurs d'authentification:

Un utilisateur sait quelque chose (un mot de passe, par exemple)
Un utilisateur a quelque chose (c'est-à-dire un porte-clés)
Un utilisateur est quelque chose (c'est-à-dire un scan de la rétine)

Généralement, les sites Web n'appliquent que la stratégie n ° 1. Même la plupart des banques n'appliquent que la politique 1. Elles s'appuient plutôt sur un & "Sait quelque chose d'autre &"; approche de l'authentification à deux facteurs. (IE: un utilisateur connaît son mot de passe et le nom de jeune fille de sa mère.) Si vous le pouvez, un moyen d'ajouter un second facteur d'authentification n'est pas trop difficile.

Si vous pouvez générer environ 256 caractères aléatoires, vous pouvez structurer cela dans un tableau 16 & # 215; 16, puis demander à l'utilisateur de vous donner la valeur dans le tableau de la cellule A-14, par exemple. . Lorsqu'un utilisateur s'inscrit ou modifie son mot de passe, donnez-lui la table et dites-lui de l'imprimer et de l'enregistrer.

Le problème avec cette approche est que, lorsqu'un utilisateur oublie son mot de passe, comme il le fera, vous ne pouvez pas offrir le standard & "; répondez à cette question et saisissez un nouveau mot de passe &" ;, puisque c'est vulnérable à la force brute aussi. En outre, vous ne pouvez pas le réinitialiser et leur en envoyer un nouveau, car leur courrier électronique pourrait également être compromis. (Voir: Makeuseof.com et leur domaine volé.)

Une autre idée (qui concerne les chatons) est ce que BOA appelle SiteKey (je pense que le nom de la marque leur a été attribué). En bref, vous demandez à l'utilisateur de télécharger une image lors de son inscription et, lorsqu'il tente de se connecter, de lui demander de choisir son image parmi 8 ou 15 (ou plus) au hasard. Ainsi, si un utilisateur télécharge une photo de son chaton, il est théoriquement le seul à savoir exactement quelle image est la leur parmi tous les autres chatons (ou fleurs ou autres). La seule vulnérabilité réelle de cette approche est l’attaque de type "man-in-the-middle".

Une autre idée (pas de chatons cependant) est de suivre les adresses IP avec lesquelles les utilisateurs accèdent au système et de les obliger à effectuer une authentification supplémentaire (captcha, choisir un chat, choisir une clé dans ce tableau) lorsqu’ils se adresse qu'ils n'ont pas avant. De même, similaire à GMail, permet à l’utilisateur de voir à partir de quoi il s’est connecté récemment.

Modifier, nouvelle idée:

Une autre façon de valider les tentatives de connexion consiste à vérifier si l'utilisateur est issu de votre page de connexion. Vous ne pouvez pas vérifier les référents, car ils peuvent être facilement falsifiés. Ce dont vous avez besoin est de définir une clé dans la variable _SESSION lorsque l'utilisateur visualise la page de connexion, puis de vérifier que cette clé existe lors de l'envoi de ses informations de connexion. Si bot ne soumet pas à partir de la page de connexion, il ne pourra pas se connecter. Vous pouvez également faciliter cela en impliquant JavaScript dans le processus, soit en l'utilisant pour définir un cookie, soit en ajoutant des informations au formulaire après son chargement. Vous pouvez également diviser le formulaire en deux envois différents (l’utilisateur entre son nom d’utilisateur, l’envoie, puis, sur une nouvelle page, entre son mot de passe et le soumet à nouveau.)

La clé, dans ce cas, est l’aspect le plus important. Une méthode courante pour les générer consiste à combiner les données de l'utilisateur, leur adresse IP et l'heure à laquelle elles ont été soumises.

Je dois vous demander si vous avez effectué une analyse coûts-avantages de ce problème. on dirait que vous essayez de vous protéger contre un attaquant qui a une présence suffisante sur le Web pour deviner un certain nombre de mots de passe, en envoyant peut-être 3 à 5 demandes par adresse IP (puisque vous avez rejeté la limitation de la propriété intellectuelle). Combien coûte (à peu près) ce genre d'attaque? Est-ce plus cher que la valeur des comptes que vous essayez de protéger? Combien de botnets gargantues veulent ce que vous avez?

La réponse est peut-être non, mais si c'est le cas, j'espère que vous obtiendrez l'aide d'un professionnel de la sécurité. la compétence de programmation (et le score StackOverflow) ne sont pas fortement corrélés au savoir-faire en matière de sécurité.

J'avais déjà répondu à une question très similaire à l'adresse Comment puis-je limiter les tentatives de connexion des utilisateurs en PHP ? Je vais réitérer la solution proposée ici car je pense que beaucoup d'entre vous le trouverez informatif et utile pour voir du code réel. N'oubliez pas que l'utilisation d'un CAPTCHA n'est peut-être pas la meilleure solution en raison des algorithmes de plus en plus précis utilisés dans les busters CAPTCHA de nos jours:

Vous ne pouvez pas simplement empêcher les attaques DoS en chaînant la limitation à une adresse IP ou à un nom d'utilisateur. Enfer, vous ne pouvez même pas vraiment empêcher les tentatives de connexion rapide avec cette méthode.

Pourquoi? L'attaque pouvant concerner plusieurs adresses IP et plusieurs comptes d'utilisateurs, elle permet d'éviter les tentatives de limitation.

J'ai vu dans d'autres publications que, dans l'idéal, vous devriez suivre toutes les tentatives de connexion infructueuses sur le site et les associer à un horodatage, par exemple:

CREATE TABLE failed_logins(
    id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    username VARCHAR(16) NOT NULL,
    ip_address INT(11) UNSIGNED NOT NULL,
    attempted DATETIME NOT NULL
) engine=InnoDB charset=UTF8;

Déterminez certains délais en fonction du nombre global de connexions échouées au cours d'une période donnée. Vous devez vous baser sur les données statistiques extraites de votre failed_logins table, car elles changeront avec le temps en fonction du nombre d'utilisateurs et du nombre d'utilisateurs pouvant rappeler (et taper) leur mot de passe.

10 failed attempts = 1 second
20 failed attempts = 2 seconds
30 failed attempts = reCaptcha

Interrogez la table à chaque tentative de connexion échouée pour trouver le nombre de connexions échouées pour une période donnée, par exemple 15 minutes:

SELECT COUNT(1) AS failed FROM failed_logins WHERE attempted > DATE_SUB(NOW(), INTERVAL 15 minute);

Si le nombre de tentatives au cours de la période donnée dépasse votre limite, appliquez la limitation ou forcez tous les utilisateurs à utiliser un captcha (c.-à-d. reCaptcha) jusqu'à ce que le nombre de tentatives infructueuses soit inférieur au seuil. .

// array of throttling
$throttle = array(10 => 1, 20 => 2, 30 => 'recaptcha');

// assume query result of $sql is stored in $row
$sql = 'SELECT MAX(attempted) AS attempted FROM failed_logins';
$latest_attempt = (int) date('U', strtotime($row['attempted']));
// get the number of failed attempts
$sql = 'SELECT COUNT(1) AS failed FROM failed_logins WHERE attempted > DATE_SUB(NOW(), INTERVAL 15 minute)';
// assume the number of failed attempts was stored in $failed_attempts
krsort($throttle);
foreach ($throttle as $attempts => $delay) {
    if ($failed_attempts > $attempts) {
        // we need to throttle based on delay
        if (is_numeric($delay)) {
            $remaining_delay = time() - $latest_attempt - $delay;
            // output remaining delay
            echo 'You must wait ' . $remaining_delay . ' seconds before your next login attempt';
        } else {
            // code to display recaptcha on login form goes here
        }
        break;
    }
}

L'utilisation de reCaptcha à un certain seuil garantirait qu'une attaque provenant de plusieurs fronts serait minimisée et que les utilisateurs normaux du site ne subiraient pas de retard important pour les tentatives de connexion légitimes infructueuses. Je ne peux pas garantir la prévention, car il a déjà été développé pour que les CAPTCHA puissent être éliminés. Il existe des solutions alternatives, peut-être une variante de & "Nommez cet animal &"; Qui pourrait très bien fonctionner comme substitut.

Pour résumer le schéma de Jens dans un diagramme / base de règles de transition de pseudo-état:

utilisateur + mot de passe - > entrée
utilisateur +! mot de passe - > refusé
utilisateur + connu_IP (utilisateur) - > porte d'entrée, // never throttle
utilisateur + unknown_IP (utilisateur) - > chatière
(# refusée > n) via des volets (site) - > catflaps papillon (site) // slow the bots
catflap + throttle + password + captcha - > entrée // humans still welcome
catflap + throttle + password +! captcha - > refusé // a correct guess from a bot

Observations:

N'étouffez jamais la porte d'entrée. La police de l'État d'Elbonian a votre ordinateur chez vous mais ne peut pas vous interroger. La force brute est une approche viable de votre ordinateur.
Si vous fournissez un " Vous oubliez votre mot de passe? " lien, votre compte de messagerie devient alors partie intégrante de la surface d'attaque.

Ces observations couvrent un type d'attaque différent de celui que vous tentez de contrer.

On dirait que vous essayez de vous défendre contre brute distribuée lente force . Pas grand-chose à faire à ce sujet. Nous utilisons une infrastructure à clé publique et aucune connexion par mot de passe. Cela aide, mais si vos clients changent de poste de travail de temps en temps, cela n’est pas très applicable.

Avertissement: je travaille pour une entreprise à deux facteurs, mais je ne suis pas ici pour le brancher. Voici quelques observations.

Les cookies peuvent être volés avec XSS et les navigateurs. Les utilisateurs changent généralement de navigateur ou effacent leurs cookies.

Les adresses IP source sont à la fois variables dynamiquement et spoofables simultanément.

Captcha est utile, mais n'authentifie pas un humain spécifique.

Plusieurs méthodes peuvent être combinées avec succès, mais le goût est de mise.

La complexité des mots de passe est bonne, tout ce qui est basé sur les mots de passe dépend de manière critique des mots de passe ayant une entropie suffisante. IMHO, un mot de passe fort écrit dans un emplacement physique sécurisé est préférable à un mot de passe faible en mémoire. Les gens savent comment évaluer la sécurité des documents papier bien mieux qu'ils ne savent comprendre l'entropie effective dans le nom de leur chien lorsqu'ils sont utilisés comme mot de passe pour trois sites Web différents. Envisagez de donner aux utilisateurs la possibilité d’imprimer une grande ou une petite page contenant des codes de passe à usage unique.

Des questions de sécurité telles que & "Quelle était votre mascotte de lycée &"; sont principalement une autre forme moche de & "quelque chose que vous connaissez &"; la plupart sont facilement concevables ou sont carrément du domaine public.

Comme vous l'avez noté, limiter les tentatives de connexion infructueuses est un compromis entre la prévention des attaques par force brute et la facilité de création d'un compte. Les stratégies de verrouillage agressives peuvent refléter un manque de confiance en l'entropie des mots de passe.

Personnellement, je ne vois de toute façon pas l’avantage d’imposer l’expiration du mot de passe sur un site Web. L'attaquant obtient votre mot de passe une fois. Il peut alors le modifier et se conformer à cette politique aussi facilement que possible. L’un des avantages est peut-être que l’utilisateur remarquera plus tôt si l’attaquant modifie le mot de passe du compte. Il serait même préférable que l'utilisateur soit averti avant que l'attaquant ne puisse accéder. Des messages comme & Quot; N tentatives infructueuses depuis la dernière connexion & Quot; sont utiles à cet égard.

La meilleure sécurité provient d’un deuxième facteur d’authentification qui est hors bande par rapport au premier. Comme vous l'avez dit, les jetons de matériel dans le & "Quelque chose que vous avez &"; sont géniaux, mais beaucoup (pas tous) ont une réelle surcharge administrative associée à leur distribution. Je ne connais aucune biométrie & "; Quelque chose que vous êtes &"; bonnes solutions pour les sites Web. Certaines solutions à deux facteurs fonctionnent avec des fournisseurs OpenID, certaines ont des SDK PHP / Perl / Python.

Ma plus haute recommandation est simplement de vous assurer que vous tenez les utilisateurs informés des tentatives de connexion incorrectes à leurs comptes-- Les utilisateurs prendront probablement la force de leur mot de passe beaucoup plus au sérieux si on leur présente des preuves que quelqu'un essaie réellement d'accéder à leur compte.

J'ai en fait surpris quelqu'un qui a piraté le compte myspace de mon frère parce qu'il avait essayé d'accéder au compte gmail que j'avais configuré pour lui et qui avait utilisé la fonctionnalité de "réinitialisation de mon mot de passe par courrier électronique" ... qui se trouvait dans ma boîte de réception.

Pourquoi ne pas demander un mot de passe à utilisation unique avant de saisir leur mot de passe normal? Cela rendrait très évident que quelqu'un attaquait avant d'avoir beaucoup d'occasions de deviner le mot de passe principal?
Conservez un nombre / taux global d’échecs de connexion - c’est l’indicateur d’une attaque - lorsqu’une attaque est plus stricte concernant les échecs de connexion, par exemple. bannir plus rapidement les adresses IP.

Je ne crois pas qu'il existe une réponse parfaite, mais je serais enclin à l'aborder en essayant de confondre les robots si une attaque est détectée.

De mémoire:

Basculez vers un autre écran de connexion. Il comporte plusieurs blancs de noms d'utilisateur et de mots de passe qui apparaissent réellement, mais un seul d'entre eux est au bon endroit. Les noms de champ sont RANDOM - une clé de session est envoyée avec l'écran de connexion, le serveur peut alors savoir quels champs sont quoi. Réussie ou échouée, elle est ensuite rejetée afin que vous ne puissiez pas tenter une attaque par rejeu. Si vous refusez le mot de passe, ils obtiennent un nouvel identifiant de session.

Tout formulaire soumis avec des données dans un champ incorrect est supposé provenir d'un robot - la connexion échoue, le point et cette adresse IP est limitée. Assurez-vous que les noms de champs aléatoires ne correspondent jamais aux noms de champs légitimes afin qu'une personne utilisant quelque chose qui se souvienne des mots de passe ne soit pas induite en erreur.

Ensuite, que diriez-vous d’un autre type de captcha: vous avez une série de questions qui ne poseront pas de problèmes à un humain. Cependant, ils ne sont PAS aléatoires. Quand l'attaque commence, tout le monde se voit poser la question n ° 1. Après une heure, la question n ° 1 est rejetée, ne doit plus être utilisée et tout le monde reçoit la question n ° 2, etc. "

L'attaquant ne peut pas demander le téléchargement de la base de données à mettre dans son robot en raison de la nature jetable des questions. Il doit envoyer de nouvelles instructions à son botnet dans l’heure pour pouvoir faire quoi que ce soit.

Étant donné que de nombreuses personnes ont inclus CAPTCHA en tant que mécanisme humain de secours, j'ajoute une question et un sujet StackOverflow antérieurs sur l'efficacité de CAPTCHA.

Est-ce que reCaptcha a été fissuré / piraté / OCR & # 8217 ; d / vaincu / cassé?

L'utilisation de CAPTCHA ne limite pas les améliorations de votre limitation et de vos autres suggestions, mais je pense que le nombre de réponses incluant CAPTCHA comme solution de secours devrait tenir compte des méthodes humaines disponibles pour les personnes cherchant à rompre la sécurité.

Vous pouvez également limiter en fonction de la force du mot de passe d'un utilisateur.

Lorsqu'un utilisateur enregistre ou modifie son mot de passe, vous calculez un indice de solidité pour son mot de passe, compris entre 1 et 10.

Quelque chose comme " mot de passe " marque un 1 alors que & «c6eqapRepe7et * Awr @ ch &»; pourrait marquer un 9 ou 10 et plus le score est élevé, plus il faut de temps pour que l’étranglement se déclenche.

Lorsque je pose cette question, la première réponse que j'ai l'habitude d'entendre est de changer de port, mais oubliez cela et désactivez simplement IPv4. Si vous n'autorisez que les clients des réseaux IPv6, vous ne priez plus pour une analyse de réseau simple et les attaquants auront recours à des recherches DNS. Ne courez pas à la même adresse que votre Apache (AAAA) / Sendmail (MX - & Gt; AAAA) / qu'avez-vous donné à tout le monde (AAAA). Assurez-vous que votre zone ne peut pas être xferd, attendez-vous à ce que votre zone puisse être téléchargée par qui que ce soit?

Si les robots trouvent de nouveaux noms d’hôte dans la configuration de votre serveur, ajoutez simplement du charabia à vos noms d’hôtes et modifiez votre adresse. Laissez les anciens noms et même configurez ** noms de honeypot pour le réseau de bot sur lesquels le délai d’expiration expire.

** Testez vos enregistrements inversés (PTR) (sous ip6.arpa.) pour voir s’ils peuvent être utilisés pour cibler des disques / 4 contenant des enregistrements VS / 4 qui ne le sont pas. C'EST À DIRE. Typiquement, ip6.arpa aurait ~ 32 & "; &" Dans une adresse, mais essayer avec les derniers manquants pourrait échapper aux blocs réseau qui ont des enregistrements par rapport à d’autres qui n’en ont pas. Si vous allez plus loin, il devient possible de sauter de grandes portions de l'espace d'adressage.

Dans le pire des cas, les utilisateurs devront configurer un tunnel IPv6, ce n’est pas comme si ils devaient aller jusqu’à VPN dans une DMZ ... Bien que l’on se demande pourquoi ce n’est pas la première option.

De plus, Kerberos est cool, mais IMHO LDAP explose (Qu'est-ce qui ne va pas techniquement avec NISPlus? J'ai lu que Sun avait décidé que les utilisateurs souhaitaient LDAP et, à cause de cela, ils avaient abandonné NIS +). Kerberos fonctionne correctement sans LDAP ou NIS, il suffit de gérer les utilisateurs hôte par hôte. L’utilisation de Kerberos vous donne une infrastructure à clé publique facile à utiliser, sinon automatisée.

Un peu tard ici, mais je pensais, en supposant que ce soit un cas difficile: l'attaquant utilise de nombreuses adresses IP aléatoires, des noms d'utilisateur aléatoires et un mot de passe aléatoire sélectionné dans une liste des 10 000 adresses les plus populaires, par exemple.

Une chose que vous pouvez faire, en particulier si le système semble attaqué en ce sens que de nombreuses tentatives de mot de passe erronées ont été tentées, en particulier si le mot de passe est d'entropie faible, est de poser une question secondaire telle que les prénoms de vos parents. , par exemple. Si un attaquant touche un million de comptes en essayant le mot de passe 'password1', il en aura de grandes chances pour beaucoup, mais leurs chances d'obtenir également le nom exact réduiraient considérablement les succès.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow