Quelle est la meilleure contre-mesure répartie de la force brute?
Tout d'abord, un peu d'histoire: ce n'est un secret pour personne que j'implémente un système auth + auth pour CodeIgniter, et jusqu'à présent je gagne (pour ainsi dire). Mais je me suis heurté à un défi assez non trivial (que la plupart des bibliothèques d'authentification manquent complètement, mais j'insiste pour le gérer correctement): comment gérer intelligemment à grande échelle, distribué, attaques par force brute de nom d'utilisateur variable .
Je connais toutes les astuces habituelles:
- Limiter le nombre de tentatives infructueuses par IP/hôte et refuser l'accès aux contrevenants (par exemple Fail2Ban) - ce qui ne fonctionne plus puisque les botnets sont devenus plus intelligents
- La combinaison de ce qui précède avec une liste noire des "mauvais" IP/hôtes connus (par exemple DenyHosts) - qui repose sur des botnets tombant pour # 1, ce qu'ils ne font de plus en plus
- Listes blanches IP/Hôte combinées avec l'authentification traditionnelle (malheureusement inutile avec 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/heures, et limitation (suspension) de toutes les tentatives de connexion après cela pendant un certain nombre de minutes/heures (avec le problème que le DoS vous attaque devient un jeu d'enfant de botnet)
- Signatures numériques obligatoires (certificats de clé publique) ou jetons matériels RSA pour tous les utilisateurs sans option de connexion/mot de passe (sans aucun doute une solution solide, mais uniquement pratique pour les services fermés et dédiés)
- Schémas de mot de passe ultra-forts appliqués (par exemple> 25 caractères non-sens avec symboles - encore une fois, trop peu pratique pour les utilisateurs occasionnels)
- Et enfin, CAPTCHA (ce qui pourrait fonctionner dans la plupart des cas, mais est ennuyeux pour les utilisateurs et pratiquement inutile contre un attaquant déterminé et ingénieux )
Maintenant, ce ne sont que des idées théoriquement réalisables. Il y a beaucoup d'idées de détritus qui font exploser le site (par exemple à des attaques DoS triviales). Ce que je veux, c'est quelque chose de mieux. Et par mieux, je veux dire:
Il doit être sécurisé (+) contre le DoS et les attaques par force brute, et ne pas introduire de nouvelles vulnérabilités qui pourraient permettre à un bot légèrement plus sournois de continuer à fonctionner sous le radar
Il 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 générale du Web (c.-à-d. Un taux de désabonnement élevé, un volume élevé et un enregistrement ouvert pouvant être effectué par des non-programmeurs)
Cela ne peut pas entraver l'expérience utilisateur au point où les utilisateurs occasionnels seront ennuyés ou frustrés (et abandonneront potentiellement le site)
Cela ne peut pas impliquer de chatons, sauf s'ils sont vraiment vraiment sécurisés chatons
(+) Par "sécurisé", je veux dire au moins aussi sécurisé que la capacité d'un utilisateur paranoïaque à garder son mot de passe secret
Alors - écoutons! Comment feriez-vous? Connaissez-vous une meilleure pratique que je n'ai pas mentionnée (oh dites-moi que oui)? J'avoue avoir ma propre idée (en combinant les idées de 3 et 4), mais je laisse les vrais experts s'exprimer avant de m'embarrasser ;-)
D'accord, assez de décrochage; voici ce que j'ai trouvé jusqu'à présent
(désolé, long post à venir. Soyez courageux, ami, le voyage en vaudra la peine)
Combiner les méthodes 3 et 4 de la publication d'origine en une sorte de liste blanche `` floue '' ou dynamique, puis - et voici l'astuce - ne pas bloquer les adresses IP non mises en liste blanche, simplement les limiter en enfer et retour .
Notez que cette mesure est uniquement destinée à contrecarrer ce type d'attaque très spécifique. Dans la pratique, bien sûr, cela fonctionnerait en combinaison avec d'autres meilleures pratiques d'authentification: limitation du nom d'utilisateur fixe, limitation par IP, stratégie de mot de passe fort appliquée par code, connexion de cookie non limitée, hachage de tous les équivalents de mot de passe avant de les enregistrer, jamais en utilisant des questions de sécurité, etc.
Hypothèses sur le scénario d'attaque
Si un attaquant cible des noms d'utilisateurs variables, la limitation de notre nom d'utilisateur ne se déclenche pas. Si l'attaquant utilise un botnet ou a accès à une large plage IP, notre limitation IP est impuissante. Si l'attaquant a pré-gratté notre liste d'utilisateurs (généralement possible sur les services Web à inscription ouverte), nous ne pouvons pas détecter une attaque en cours en fonction du 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), une telle attaque fera disparaître tout notre site pendant la durée de l'attaque plus la période de limitation.
Nous devons donc faire autre chose.
La première partie de la contre-mesure: liste blanche
Ce dont nous pouvons être assez sûrs, c'est que l'attaquant n'est pas en mesure de détecter et d'usurper dynamiquement les adresses IP de plusieurs milliers de nos utilisateurs (+). Ce qui rend la liste blanche réalisable. En d'autres termes: pour chaque utilisateur, nous stockons une liste des IP (hachées) à partir desquelles l'utilisateur s'est précédemment (récemment) connecté.
Ainsi, notre schéma de liste blanche fonctionnera comme une "porte d'entrée" verrouillée, où un utilisateur doit être connecté à partir de l'une de ses "bonnes" adresses IP afin de se connecter. Une attaque par force brute sur cette "porte d'entrée" serait pratiquement impossible (+).
(+) sauf si l'attaquant "possède" soit le serveur, toutes les boîtes de nos utilisateurs, soit la connexion elle-même - et dans ces cas, nous n'avons plus de problème "d'authentification", nous avons un véritable pull-the de la taille d'une franchise -brancher la situation FUBAR
La deuxième partie de la contre-mesure: limitation à l'échelle du système des adresses IP non reconnues
Afin de faire fonctionner une liste blanche 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 de chat '' ouverte pour les utilisateurs se connectant à partir d'adresses IP non reconnues. L'astuce consiste à concevoir cette porte de manière à ce que les botnets soient bloqués et que les utilisateurs légitimes soient dérangés le moins possible .
Dans mon schéma, cela est réalisé en définissant un nombre maximal de tentatives de connexion infructueuses par des adresses IP non approuvées sur, disons, une période de 3 heures (il peut être plus sage d'utiliser une période plus courte ou plus longue selon le type de service), et en faisant cette restriction global, ie 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 brute vraiment lente pourrait toujours rester inaperçue, mais des vitesses trop lentes contrarient le but même de l'attaque par force brute.
Ce que j'espère accomplir avec ce mécanisme de limitation, c'est que si la limite maximale est atteinte, notre `` porte de chat '' se ferme pendant un certain temps, mais notre porte d'entrée reste ouverte aux utilisateurs légitimes se connectant 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. alors que la limitation était activée - ce serait des 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 jusqu'à ce que la limitation soit épuisée (ce qui pourrait potentiellement prendre un certain temps si l'attaquant maintenait son botnet en cours d'exécution malgré la limitation).
Pour permettre à ce petit sous-ensemble d'utilisateurs de se faufiler à travers la porte du chat autrement scellée, même si les bots martelaient encore, j'emploierais un formulaire de connexion de `` sauvegarde '' avec un CAPTCHA. Ainsi, lorsque vous affichez le message "Désolé, mais vous ne pouvez pas vous connecter à partir de cette adresse IP pour le moment", incluez un lien qui dit "connexion de sauvegarde sécurisée - HUMAINS UNIQUEMENT ( bots: pas de mensonge ) ". Blague à part, lorsqu'ils cliquent sur ce lien, donnez-leur un formulaire de connexion authentifié reCAPTCHA qui contourne la limitation à l'échelle du site. De cette façon, S'ils sont humains ET connaissent le bon login + mot de passe (et sont capables de lire les CAPTCHA), ils seront jamais refusés, même s'ils se connectent depuis un hôte inconnu et n'utilisent pas le cookie de connexion automatique.
Oh, et juste pour clarifier: comme je considère que les CAPTCHA sont généralement mauvais, l'option de connexion de `` sauvegarde '' seulement apparaîtra pendant que la limitation était active .
Il ne fait aucun doute qu'une attaque soutenue comme celle-ci constituerait toujours une forme d'attaque DoS, mais avec le système décrit en place, cela n'affecterait que ce que je soupçonne d'être un minuscule sous-ensemble d'utilisateurs, à savoir les personnes qui n'utilisent pas le cookie "souvenez-vous de moi" ET vous connectez pendant qu'une attaque se produit ET ne vous connectez à partir d'aucune de leurs 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 vraiment malchanceux personnes handicapées - seront refoulés lors d'une attaque de bot.
EDIT: En fait, j'ai pensé à un moyen de laisser même les utilisateurs ayant des problèmes avec CAPTCHA passer pendant un `` verrouillage '': au lieu de, ou en complément de la connexion de sauvegarde CAPTCHA, fournir à l'utilisateur la possibilité de recevoir un code de verrouillage à usage unique, spécifique à l'utilisateur, envoyé à son courrier électronique, qu'il peut ensuite utiliser pour contourner la limitation. Cela dépasse définitivement mon seuil de `` gêne '', mais comme il n'est utilisé qu'en tant que dernier recours pour un petit sous-ensemble d'utilisateurs, et comme il bat toujours d'être verrouillé de votre compte, ce serait acceptable.
(Notez également que aucun cela se produit 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 seulement quelques IP ou ne touche que quelques noms d'utilisateur , il sera contrecarré beaucoup plus tôt, et avec pas conséquences à l'échelle du site)
C'est donc la contre-mesure que j'implémenterai dans ma bibliothèque d'authentification, une fois que je serai convaincu qu'elle est solide et qu'il n'y a pas de solution beaucoup plus simple que j'ai ratée. Le fait est qu'il y a tellement de façons subtiles de mal faire les choses en matière de sécurité, et je ne suis pas au-dessus de faire de fausses hypothèses ou une logique sans espoir. Alors s'il vous plaît, tous les commentaires, critiques et améliorations, subtilités, etc. sont très appréciés.
Quelques étapes simples:
Mettez sur liste noire certains noms d'utilisateur courants et utilisez-les comme pot de miel. Administrateur, invité, etc ... Ne laissez personne créer des comptes avec ces noms, donc si quelqu'un essaie de se connecter, vous savez que c'est quelqu'un qui fait quelque chose qu'il ne devrait pas faire.
Assurez-vous que toute personne disposant d'un réel pouvoir sur le site dispose d'un mot de passe sécurisé. Exiger que les administrateurs/modérateurs aient des mots de passe plus longs avec un mélange de lettres, de chiffres et de symboles. Rejetez les mots de passe trivialement simples des utilisateurs réguliers avec une explication.
L'une des choses les plus simples que vous pouvez faire est de dire aux gens quand quelqu'un a essayé de se connecter à leur compte et de leur donner un lien pour signaler l'incident si ce n'est pas eux. Un simple message lorsqu'ils se connectent comme "Quelqu'un a essayé de se connecter à votre compte à 04h20 mercredi bla bla. Cliquez ici si ce n'était pas vous." Il vous permet de conserver des statistiques sur les attaques. Vous pouvez intensifier les mesures de surveillance et de sécurité si vous constatez une augmentation soudaine des accès frauduleux.
Si je comprends bien le MO des attaques par force brute, alors un ou plusieurs noms d'utilisateur sont essayés en continu.
Il y a deux suggestions que je ne pense pas avoir encore vues ici:
- J'ai toujours pensé que la pratique standard était d'avoir un court délai (une seconde environ) après chaque mauvaise 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. L'accélérateur devient de plus en plus dur à chaque mauvaise tentative (jusqu'à une limite, je suppose que le véritable utilisateur peut toujours se connecter)
Edit : En réponse aux commentaires sur un accélérateur de nom d'utilisateur: il s'agit d'un accélérateur spécifique au nom d'utilisateur sans égard à la source de l'attaque.
Si le nom d'utilisateur est limité, même une attaque coordonnée de nom d'utilisateur (multi IP, estimation unique par IP, même nom d'utilisateur) serait interceptée. Les noms d'utilisateur individuels sont protégés par l'accélérateur, même si les attaquants sont libres d'essayer un autre utilisateur/passe pendant le délai d'expiration.
Du point de vue des attaquants, pendant le délai d'attente, vous pourrez peut-être deviner pour la première fois 100 mots de passe et découvrir rapidement un mot de passe incorrect par compte. Vous ne pourrez peut-être faire qu'une estimation de 50 secondes pour la même période.
Du point de vue d'un compte utilisateur, il faut toujours le même nombre moyen de suppositions pour briser le mot de passe, même si les suppositions proviennent de plusieurs sources.
Pour les attaquants, au mieux, ce sera le même effort pour casser 100 comptes que pour 1 compte, mais comme vous n'accélérez pas à l'échelle du site, vous pouvez accélérer rapidement.
Raffinements supplémentaires:
- détecter les adresses IP qui devinent plusieurs comptes - 408 Request Timeout
- détecter les IP qui devinent le même compte - 408 Request Timeout après un grand nombre (disons 100) de suppositions.
Idées d'interface utilisateur (peut ne pas convenir dans ce contexte), qui peuvent également affiner ce qui précède:
- si vous contrôlez le paramètre du mot de passe, montrer à l'utilisateur la force de son mot de passe l'encourage à en choisir un meilleur.
- si vous contrôlez la connexion page, après un petit nombre (disons 10) de suppositions d'un seul nom d'utilisateur, offrez un CAPTCHA.
Il existe trois facteurs d'authentification:
- Un utilisateur sait quelque chose (c'est-à-dire un mot de passe)
- Un utilisateur a quelque chose (c'est-à-dire un porte-clés)
- Un utilisateur est quelque chose (ie, scan rétine)
Habituellement, les sites Web appliquent uniquement la politique n ° 1. Même la plupart des banques appliquent uniquement la politique 1. Elles s'appuient plutôt sur une approche "sait autre chose" pour 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 deuxième 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 × 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 le tableau et dites-lui de l'imprimer et de l'enregistrer.
La difficulté de cette approche est que lorsqu'un utilisateur oublie son mot de passe, comme il le fera, vous ne pouvez pas simplement proposer la norme "répondre à cette question et entrer un nouveau mot de passe", car il est également vulnérable à la force brute. De plus, vous ne pouvez pas le réinitialiser et en envoyer un nouveau par e-mail, car leur e-mail pourrait également être compromis. (Voir: Makeuseof.com et leur domaine volé.)
Une autre idée (qui implique des chatons), est ce que BOA appelle SiteKey (je crois qu'ils ont déposé le nom). En bref, l'utilisateur doit télécharger une image lors de son inscription et lorsqu'il tente de se connecter, demandez-lui de choisir son image parmi 8 ou 15 (ou plus) images aléatoires. Donc, si un utilisateur télécharge une image de son chaton, théoriquement seulement il sait exactement quelle image est la leur de tous les autres chatons (ou fleurs ou autre). La seule réelle vulnérabilité de cette approche est l'attaque de l'homme du milieu.
Une autre idée (pas de chatons cependant) consiste à suivre les adresses IP avec lesquelles les utilisateurs accèdent au système et les obligent à effectuer une authentification supplémentaire (captcha, choisir un minou, choisir une clé dans ce tableau) lorsqu'ils se connectent à partir d'une adresse qu'ils ont pas avant. De même, comme pour GMail, permet à l'utilisateur de voir où 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 provient ou non de votre page de connexion. Vous ne pouvez pas vérifier les référents, car ils peuvent être facilement truqués. Ce dont vous avez besoin est de définir une clé dans la var _SESSION lorsque l'utilisateur affiche la page de connexion, puis de vérifier que cette clé existe lorsqu'il soumet ses informations de connexion. Si le bot ne soumet pas depuis 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. Ou, vous pouvez diviser le formulaire en deux soumissions différentes (c'est-à-dire que l'utilisateur entre son nom d'utilisateur, soumet, puis sur une nouvelle page entre son mot de passe et 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, son adresse IP et l'heure à laquelle elles ont été soumises.
Je dois vous demander si vous avez fait une analyse coûts-avantages de ce problème; on dirait que vous essayez de vous protéger contre un attaquant qui a suffisamment de présence sur le Web pour deviner un certain nombre de mots de passe, envoyant peut-être 3 à 5 demandes par IP (puisque vous avez rejeté la limitation d'IP). Combien (à peu près) coûterait ce type d'attaque? Est-ce plus cher que la valeur des comptes que vous essayez de protéger? Combien de botnets gargantuesques veulent ce que vous avez?
La réponse est peut-être non - mais si c'est le cas, j'espère que vous obtenez l'aide d'un professionnel de la sécurité en quelque sorte; les compétences en programmation (et le score StackOverflow) ne sont pas fortement corrélées au savoir-faire en matière de sécurité.
J'avais déjà répondu à une question très similaire sur 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 la trouveront informative et utile pour voir du code réel. Veuillez garder à l'esprit 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 de nos jours dans les briseurs CAPTCHA:
Vous ne pouvez pas simplement empêcher les attaques DoS en enchaînant la limitation à une seule adresse IP ou nom d'utilisateur. Enfer, vous ne pouvez même pas vraiment empêcher les tentatives de connexion à tir rapide en utilisant cette méthode.
Pourquoi? Parce que l'attaque peut s'étendre sur plusieurs adresses IP et comptes d'utilisateurs pour contourner votre limitation tentatives.
J'ai vu ailleurs que vous devriez idéalement suivre toutes les tentatives de connexion échouées sur le site et les associer à un horodatage, peut-être:
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écidez de certains retards en fonction du nombre dans l'ensemble d'échecs de connexion dans un laps de temps donné. Vous devez baser cela sur des données statistiques extraites de votre failed_logins table telle qu'elle va changer au fil du temps en fonction du nombre d'utilisateurs et du nombre d'entre eux qui peuvent se rappeler (et taper) leur mot de passe.
10 failed attempts = 1 second
20 failed attempts = 2 seconds
30 failed attempts = reCaptcha
Recherchez le tableau à chaque tentative de connexion ayant échoué pour trouver le nombre de connexions ayant échoué pour une période donnée, disons 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 de temps donnée dépasse votre limite, appliquez la limitation ou forcez tous les utilisateurs à utiliser un captcha (c'est-à-dire reCaptcha) jusqu'à ce que le nombre de tentatives infructueuses au cours de la période de temps donnée 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 sur plusieurs fronts serait minimisée et que les utilisateurs normaux du site ne subiraient pas de retard significatif pour les tentatives de connexion échouées légitimes. Je ne peux pas garantir la prévention, car il a déjà été développé que CAPTCHA peut être détruit. Il existe des solutions alternatives, peut-être une variante de "Nommez cet animal", qui pourraient très bien fonctionner comme substitut.
Pour résumer le schéma de Jens en un pseudo diagramme de transition d'état/base de règles:
- 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) -> catflap
- (#denied> n) via catflaps (site) -> gaz catflaps (site)
// slow the bots - catflap + accélérateur + mot de passe + captcha -> entrée
// humans still welcome - catflap + accélérateur + mot de passe +! captcha -> refusé
// a correct guess from a bot
Observations:
- N'accélérez jamais la porte avant. 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 à partir de votre ordinateur.
- Si vous fournissez un "Oublié votre mot de passe?" lien, votre compte de messagerie devient une partie de la surface d'attaque.
Ces observations couvrent un type d'attaque différent de ceux que vous essayez de contrer.
On dirait que vous essayez de vous défendre contre force brute distribuée lente . Vous ne pouvez pas faire grand-chose à ce sujet. Nous utilisons une PKI et aucune connexion par mot de passe. Cela aide, mais si vos clients changent de poste de temps en temps, ce 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 vulns du navigateur. Les utilisateurs changent généralement de navigateur ou effacent leurs cookies.
Les adresses IP source sont simultanément dynamiquement variables et usurpatrices.
Le captcha est utile, mais n'authentifie pas un être humain spécifique.
Plusieurs méthodes peuvent être combinées avec succès, mais le bon goût est certainement de mise.
La complexité du mot de passe est bonne, tout ce qui est basé sur un mot de passe dépend de manière critique des mots de passe ayant une entropie suffisante. À mon humble avis, un mot de passe fort écrit dans un emplacement physique sécurisé est meilleur qu'un mot de passe faible en mémoire. Les gens savent évaluer la sécurité des documents papier beaucoup mieux qu'ils ne savent comment comprendre l'entropie effective du nom de leur chien lorsqu'il est utilisé 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 pleine de codes d'accès à usage unique.
Les questions de sécurité comme "quelle était votre mascotte de lycée" sont pour la plupart une autre forme moche de "quelque chose que vous savez", la plupart d'entre elles sont facilement devinables ou carrément dans le domaine public.
Comme vous l'avez noté, la limitation des tentatives de connexion infructueuses est un compromis entre la prévention des attaques par force brute et la facilité de DoSing d'un compte. Les politiques de verrouillage agressives peuvent refléter un manque de confiance dans l'entropie des mots de passe.
Personnellement, je ne vois pas l'avantage de faire expirer le mot de passe sur un site Web de toute façon. L'attaquant obtient votre mot de passe une fois, il peut le changer ensuite et se conformer à cette politique aussi facilement que possible. L'un des avantages est peut-être que l'utilisateur peut remarquer plus tôt si l'attaquant modifie le mot de passe du compte. Il serait encore mieux que l'utilisateur soit informé d'une manière ou d'une autre avant que l'attaquant n'y accède. Des messages comme "N tentatives infructueuses depuis la dernière connexion" 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 matériels dans le "quelque chose que vous avez" sont excellents, mais beaucoup (pas tous) ont de réels frais d'administration associés à leur distribution. Je ne connais aucune solution biométrique "quelque chose que vous êtes" bonne pour les sites Web. Certaines solutions à deux facteurs fonctionnent avec des fournisseurs openid, certaines ont des SDK PHP/Perl/Python.
Que diriez-vous d'exiger un mot de passe à usage unique avant d'entrer son mot de passe normal? Cela rendrait très évident que quelqu'un attaquait avant d'avoir de nombreuses occasions de deviner le mot de passe principal?
Gardez un nombre/taux global d'échecs de connexion - c'est l'indicateur d'une attaque - pendant une attaque, soyez plus strict sur les échecs de connexion, par exemple interdire les adresses IP plus rapidement.
Ma recommandation la plus élevée est de simplement 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 s'ils se voient présenter la preuve que quelqu'un est essayant réellement d'accéder à leur compte.
En fait, j'ai attrapé 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 utilisé la fonction `` réinitialiser mon mot de passe par e-mail '' ... qui est allée dans ma boîte de réception.
Vous pouvez également accélérer en fonction de la force du mot de passe d'un utilisateur.
Lorsqu'un utilisateur enregistre ou modifie son mot de passe, vous calculez une cote de résistance pour son mot de passe, disons entre 1 et 10.
Quelque chose comme "mot de passe" marque un 1 tandis que "c6eqapRepe7et * Awr @ ch" peut marquer un 9 ou 10 et plus le score est élevé, plus il faut de temps pour que la limitation se déclenche.
La première réponse que j'entends habituellement en posant cette question est de changer les ports, 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 simple analyse du réseau et les attaquants auront recours à des recherches DNS. Ne courez pas sur la même adresse que votre Apache (AAAA)/Sendmail (MX-> AAAA)/qu'avez-vous donné à tout le monde (AAAA). Assurez-vous que votre zone ne peut pas être xferd, attendez que vous autorisiez le téléchargement de votre zone par quelqu'un?
Si les robots trouvent que votre serveur configure de nouveaux noms d'hôtes, ajoutez simplement du charabia à vos noms d'hôtes et changez votre adresse. Laissez les anciens noms et même configurer ** les noms de pots de miel pour que le réseau de bots expire.
** Testez vos enregistrements inversés (PTR) (sous ip6.arpa.) Pour voir s'ils peuvent être utilisés pour mettre à zéro les on/4 qui ont des enregistrements VS/4 qui n'en ont pas. C'EST À DIRE. En général, ip6.arpa aurait ~ 32 "." S dans une adresse, mais essayer avec les derniers manquants pourrait échapper aux blocs réseau qui ont des enregistrements VS 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 s'ils devaient aller jusqu'au VPN dans une DMZ ... Bien qu'on se demande pourquoi ce n'est pas la première option.
Kerberos est également cool, mais IMHO LDAP souffle (Qu'est-ce qui ne va pas techniquement avec NISPlus? J'ai lu que Sun a décidé que les utilisateurs voulaient LDAP et à cause de cela, ils ont abandonné NIS +). Kerberos fonctionne bien sans LDAP ou NIS, il suffit de gérer les utilisateurs hôte par hôte. L'utilisation de Kerberos vous offre une PKI facile à utiliser, sinon automatisée.
Un peu en retard ici, mais je pensais, en supposant un cas difficile - l'attaquant utilise beaucoup d'adresses IP aléatoires, des noms d'utilisateurs aléatoires et un mot de passe aléatoire sélectionné dans, par exemple, une liste des 10 000 plus populaires.
Une chose que vous pourriez faire, surtout si le système semble attaqué en ce qu'il y a beaucoup de tentatives de mot de passe incorrectes sur le système et surtout si le mot de passe est à faible entropie, c'est de poser une question secondaire comme quels sont les prénoms de vos parents, par exemple . Si un attaquant frappe un million de comptes en essayant le mot de passe 'password1', il y a de fortes chances qu'ils obtiennent beaucoup, mais leurs chances d'obtenir également les bons noms réduiraient considérablement les succès.
Étant donné que plusieurs personnes ont inclus CAPTCHA comme mécanisme humain de secours, j'ajoute une question et un fil StackOverflow antérieurs sur l'efficacité de CAPTCHA.
reCaptcha a-t-il été piraté/piraté/OCR/vaincu/cassé?
L'utilisation de CAPTCHA ne limite pas les améliorations de votre limitation et d'autres suggestions, mais je pense que le nombre de réponses qui incluent CAPTCHA comme solution de rechange devrait prendre en compte les méthodes humaines disponibles pour les personnes qui cherchent à briser la sécurité.
Je ne crois pas qu'il y ait une réponse parfaite mais je serais enclin à l'approcher en essayant de confondre les robots si une attaque est détectée.
Du haut de mon esprit:
Basculez vers un autre écran de connexion. Il a plusieurs blancs de nom d'utilisateur et de mot de passe qui apparaissent vraiment, mais un seul d'entre eux est au bon endroit. Les noms de champs sont ALÉATOIRES - une clé de session est envoyée avec l'écran de connexion, le serveur peut alors savoir quels champs sont quoi. Réussir ou échouer, il est ensuite rejeté afin que vous ne puissiez pas essayer une attaque de relecture - si vous rejetez le mot de passe, ils obtiennent un nouvel ID de session.
Tout formulaire soumis avec des données dans un champ incorrect est supposé provenir d'un robot - la connexion échoue, 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 que quelqu'un qui utilise quelque chose qui se souvient des mots de passe ne soit pas trompé.
Ensuite, que diriez-vous d'un autre type de captcha: vous avez une série de questions qui ne causeront pas de problèmes à un humain. Cependant, ils sont ET NON aléatoires. Lorsque l'attaque commence, tout le monde se voit poser la question n ° 1. Après une heure, la question # 1 est jetée, pour ne plus jamais être utilisée et tout le monde reçoit la question # 2 et ainsi de suite.
L'attaquant ne peut pas sonder pour télécharger 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 qui suit pour avoir la possibilité de faire quoi que ce soit.