Quelle est la contre-mesure de la force Brute la mieux répartie?

quelques étapes simples:

liste noire de certains noms d'utilisateurs communs, et les utiliser comme un honeypot. Admin, invité, etc... Ne laissez personne créer des comptes avec ces noms, donc si quelqu'un essaie de les enregistrer, vous savez que c'est quelqu'un qui fait quelque chose qu'il ne devrait pas faire.

assurez-vous que tous ceux qui ont un réel pouvoir sur le site ont un mot de passe sécurisé. Exiger des administrateurs / modérateurs d'avoir des mots de passe plus longs avec un mélange de lettres, de nombres et de symboles. Rejeter des mots de passe trivialement simples d'utilisateurs réguliers avec une explication.

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'était pas eux. Un simple message quand ils se connectent comme " Quelqu'un a essayé de se connecter à votre compte à 4:20 mercredi blablabla. Cliquez ici si ce n'était pas vous."Il vous permet de garder quelques statistiques sur les attaques. Vous pouvez renforcer la surveillance et les mesures de sécurité si vous voir qu'il y a une augmentation soudaine frauduleuses d'accès.

si je comprends le MO des attaques par la force brute correctement, alors 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 norme était d'avoir un court délai (une seconde) après chaque mauvaise connexion pour chaque utilisateur. Cela freine la force brute, mais je ne sais pas combien de temps un retard d'une seconde pourrait tenir à distance une attaque du dictionnaire. (dictionnaire de 10 000 mots == 10 000 secondes == environ 3 heures. Hum. Pas assez bon.)
• au lieu d'un ralentissement à l'échelle du site, pourquoi pas un accélérateur de nom d'utilisateur. La manette des gaz devient de plus en plus dure à chaque tentative erronée (jusqu'à une limite, je suppose que l'utilisateur réel peut encore se connecter)

Modifier : En réponse aux commentaires sur un accélérateur de nom d'utilisateur: il s'agit d'un accélérateur spécifique de nom d'utilisateur sans égard à la source de la attaque.

si le nom d'utilisateur est étouffé, alors même une attaque coordonnée du nom d'utilisateur (multi IP, une seule estimation par IP, même nom d'utilisateur) serait Attrapée. Les noms d'utilisateur individuels sont protégés par la manette des gaz, même si les attaquants sont libres d'essayer un autre utilisateur/passe pendant le temps mort.

du point de vue des attaquants, pendant le temps d'arrêt vous pouvez être en mesure de deviner une première fois à 100 mots de passe, et rapidement découvrir un mot de passe erroné par compte. Vous pouvez ne pouvoir faire une estimation de 50 secondes que pour la même période.

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

pour les attaquants, au mieux, ce sera le même effort pour casser 100 comptes comme il le ferait 1 compte, mais puisque vous n'êtes pas étrangler sur une base de site large, vous pouvez accélérer l'accélérateur assez rapidement.

raffinements supplémentaires:

• détecter les IP qui supposent plusieurs comptes-408 demande Délai d'attente
• détecte IPs qui sont deviner le même compte-408 demande Délai après un grand (disons 100) Nombre de conjectures.

UI idées (peut-être pas approprié dans ce contexte), qui peuvent également affiner ce qui précède:

• si vous avez le contrôle du paramétrage du mot de passe, l'utilisateur comme leur mot de passe est fort les encourage à choisir un meilleur.
• si vous êtes en contrôle de la connexion page , après un petit (disons 10) Nombre de conjectures d'un seul nom d'utilisateur, offrir un CAPTCHA.

Il y a trois facteurs d'authentification:

1. Un utilisateur sait quelque chose (c'est à dire, un mot de passe)
2. Un utilisateur a quelque chose (c'est à dire, une clé fob)
3. Un utilisateur est quelque chose (c'est à dire, la rétine scan)

habituellement, les sites web ne font qu'appliquer la Politique #1. Même la plupart des banques appliquent seulement la Politique 1. Ils reposent plutôt sur une "sait quelque chose d'autre" à l'approche de l'authentification à deux facteurs. (C'est-à-dire QU'un utilisateur connaît son mot de passe et le nom de jeune fille de sa mère.) Si vous êtes capable, une façon 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 une table 16×16, puis demander à l'utilisateur de vous donner la valeur dans la table de la cellule A-14, par exemple. Quand un utilisateur s'inscrit ou change son mot de passe, donnez-leur la table et dire à l'imprimer et l'enregistrer.

la difficulté avec cette approche est que quand un utilisateur oublie son mot de passe, comme ils le feront, vous ne pouvez pas simplement offrir la norme" répondre à cette question et mettre un nouveau mot de passe", puisque c'est vulnérable à la force brute aussi bien. De plus, vous ne pouvez pas le réinitialiser et leur envoyer un nouveau courriel, puisque leur courriel pourrait aussi ê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, vous demandez à l'utilisateur de télécharger une image lorsqu'il s'inscrit, et lorsqu'il tente de se connecter, demandez-lui de choisir son image parmi 8 ou 15 (ou plus) au hasard. Donc, si un utilisateur télécharge une image de son chaton, en théorie seulement ils savent exactement quelle image est la leur parmi tous les autres chatons (ou fleurs ou autre chose). La seule vraie vunerabilité de cette approche est l'attaque de l'homme du milieu.

One plus d'IDÉE (PAS de chatons cependant), est de suivre les IPs que les utilisateurs accèdent au système avec , et les obliger à effectuer une authentification supplémentaire (captcha, choisir un kitty, choisir une clé de cette table) quand ils se connectent à partir d'une adresse qu'ils n'ont pas avant. De plus, tout comme GMail, permettre à l'utilisateur de voir où il s'est connecté depuis peu.

Modifier, Une Nouvelle Idée:

une autre façon de valider les tentatives de connexion est de vérifier si oui ou non l'utilisateur est venu 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 le var _SESSION lorsque l'utilisateur regarde la page de connexion, puis de vérifier pour s'assurer que la clé existe quand ils soumettent leurs 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, ou en ajoutant quelques informations au formulaire après qu'il a chargé. Ou, vous pouvez divisez le formulaire en deux soumissions différentes (c.-à-d., l'utilisateur entre son nom d'utilisateur, soumet, puis sur une nouvelle page entre son mot de passe et soumettre à nouveau.)

La clé, dans ce cas, est l'aspect le plus important. Une méthode commune de les générer est une certaine combinaison des données de l'Utilisateur, leur IP, et l'heure il a été soumis.

je dois vous demander si vous avez fait une analyse coûts-avantages de ce problème; il semble que vous essayez de vous protéger d'un attaquant qui a assez de présence sur le web pour deviner un certain nombre de mots de passe, en envoyant peut-être 3-5 requêtes par IP (depuis que vous avez rejeté IP étranglement). Combien (En Gros) ce genre d'attaque coûterait-il? Est-il plus cher que la valeur des comptes que vous essayez de protéger? Combien de botnets gargantuais veulent ce que vous avez?

le la réponse pourrait être non -- mais si c'est le cas, j'espère que vous obtenez de l'aide d'un professionnel de la sécurité d'une sorte quelconque; 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 à Comment puis-je réduire les tentatives de connexion de l'utilisateur en PHP . Je vais réitérer la solution proposée ici car je crois que beaucoup d'entre vous trouveront informatif et utile de voir un peu de code réel. Veuillez garder à l'esprit que L'utilisation D'un CAPTCHA pourrait ne pas être la meilleure solution en raison des algorithmes de plus en plus précis utilisés dans CAPTCHA busters de nos jours:

Vous ne pouvez pas simplement empêcher l' DoS attaque en enchaînant throttling vers le bas à une seule IP ou un nom d'utilisateur. Vous ne pouvez même pas empêcher les tentatives de connexion rapide en utilisant cette méthode.

pourquoi? " parce que l'attaque peut s'étendre à plusieurs IPs et comptes d'utilisateurs dans le but de contourner vos tentatives d'étranglement.

j'ai vu posté ailleurs qu'idéalement vous devriez être en train de pister tous les échecs tentatives de connexion à travers le site et de 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écider de certains délais sur la base du total nombre de connexions manquées dans une période donnée. Vous devez baser cela sur des données statistiques tirées de votre table failed_logins comme il sera changement dans le temps basé sur le nombre d'utilisateurs et combien d'entre eux peuvent se rappeler (et dactylographier) 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 manquée pour trouver le nombre de connexions manquées pour une période de temps 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 est au-dessus de votre limite, soit forcer l'étranglement ou forcer tous les utilisateurs à utiliser un captcha (c.-à-d. reCaptcha) jusqu'à ce que le nombre de tentatives ratées au cours de la une période donnée est inférieure 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 à partir de plusieurs fronts serait minimisée et les utilisateurs normaux du site ne connaîtraient pas un délai important pour les tentatives légitimes de connexion ratées. Je ne peux pas gaurantee prévention, car il a déjà été étendu sur le fait que CAPTCHA peut être arrêté. Il existe des solutions alternatives, peut-être une variante de " nommer ce animal", ce qui pourrait très bien fonctionner comme un substitut.

pour résumer le schéma de Jens en un pseudo-état de transition / rulebase:

1. utilisateur + mot de passe - > entrée
2. utilisateur + !mot de passe - > refusé
3. utilisateur + known_IP(utilisateur) -> porte d'entrée, // never throttle
4. utilisateur + unknown_IP(utilisateur) -> catflap
5. (#refusé > n) via catflaps(site) -> gaz catflaps(site) // slow the bots
6. catflap + throttle + mot de passe + captcha - > entrée // humans still welcome
7. catflap + gaz + mot de passe + !captcha -> refusé // a correct guess from a bot

Observations:

• N'accélérez jamais la porte d'entrée. La police D'État D'Elbonian a votre ordinateur, dans votre maison, mais est incapable de vous interroger. La force Brute est une approche viable à partir de votre ordinateur.
• si vous fournissez un " oubliez votre mot de passe?"le lien, puis 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 comptoir.

on dirait que vous essayez de vous défendre contre slow distributed brute force . Pas beaucoup que vous pouvez faire à ce sujet. Nous utilisons une ICP et aucun mot de passe. Cela aide, mais si vos clients ont des postes de travail de temps en temps, ce n'est pas très applicable.

avertissement: je travaille pour une société à deux facteurs, mais je ne suis pas ici pour le brancher. Voici quelques observations.

Cookies peuvent être volés avec XSS et vulns navigateur. Les utilisateurs changent souvent de navigateur ou effacent leurs cookies.

les adresses IP Source sont simultanément variables dynamiquement et mystifiables.

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

Plusieurs méthodes peuvent être combinées avec succès, mais bon goût est certainement dans l'ordre.

la complexité du mot de passe est bonne, Tout ce qui est basé sur le mot de passe dépend de façon critique de mots de passe ayant une entropie suffisante. IMHO, un mot de passe fort écrit dans un endroit physique sécurisé est mieux qu'un mot de passe faible en mémoire. Les gens savent comment évaluer la sécurité des documents papier beaucoup mieux qu'ils savent comment figurer l'entropie efficace dans le nom de leur chien lorsqu'il est utilisé comme un mot de passe pour trois sites web différents. Envisager de donner aux utilisateurs la possibilité d'imprimer une grande ou une petite page pleine d'utiliser des codes de passage.

les questions de sécurité comme " Quelle était votre mascotte de lycée "sont pour la plupart une autre forme de" quelque chose que vous connaissez", la plupart d'entre eux sont faciles à deviner ou purement et simplement dans le domaine public.

comme vous l'avez noté, l'étouffement des tentatives de connexion ratées est un compromis entre la prévention des attaques brutales et la facilité de dosage d'un compte. Agressif de verrouillage les politiques peuvent refléter un manque de confiance dans l'entropie des mots de passe.

personnellement, je ne vois pas l'avantage d'imposer l'expiration du mot de passe sur un site Web de toute façon. L'attaquant obtient votre mot de passe une fois, il peut alors le modifier et se conformer à cette politique aussi facilement que vous le pouvez. Peut-être un avantage est que l'utilisateur pourrait remarquer plus tôt si l'attaquant change le mot de passe du compte. Ce serait encore mieux si l'utilisateur était averti avant que l'attaquant n'obtienne l'accès. Des Messages comme" N tentatives manquées 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 tokens matériels dans le "quelque chose que vous avez" sont excellents, mais beaucoup (pas tous) ont de véritables frais généraux d'administration associés à leur distribution. Je ne connais aucune solution biométrique "quelque chose que vous êtes" bonne pour les sites web. Quelques solutions à deux facteurs avec les fournisseurs openid, certains ont des SDK PHP/Perl/Python.

peu importe la qualité de votre système, il échouera sous une attaque assez longue. Il y a quelques bonnes idées ici, sur la façon de prolonger la durée d'un mot de passe. (J'aime personnellement l'idée d'une augmentation exponentielle du taux de tentative limitant par utilisateur et par adresse IP.) Mais peu importe ce que vous allez avec, vous aurez besoin de sauvegarder avec des règles de mot de passe.

je vous encourage à comprendre à quelle vitesse un mot de passe peut être craqué, et que les utilisateurs changent eux deux fois plus souvent que cela. Espérons que cette aide.

Edit: si vous attendez beaucoup d'attaquants paresseux, nécessitant quelques CAPTCHA après plusieurs tentatives ratées est bon: il soulève la barre un peu. Si vous craignez beaucoup d'attaquants intelligents, engagez un consultant en sécurité. ;)

ma plus haute recommandation est simplement de s'assurer que vous tenir les utilisateurs informés de mauvaises tentatives de connexion à leurs comptes-- Les utilisateurs prendront probablement la force de leur mot de passe beaucoup plus au sérieux s'ils sont présentés avec la preuve que quelqu'un essaye réellement d'entrer dans leur compte.

j'ai en fait attrapé quelqu'un qui a piraté le compte myspace de mon frère parce qu'ils avaient essayé d'entrer dans le compte gmail que j'ai mis en place pour lui et utilisé la fonction "Réinitialiser mon mot de passe par courriel"... qui est allé dans ma boîte de réception.

1. Qu'en est-il de l'exigence d'un mot de passe unique avant d'entrer leur mot de passe normal? Cela rendrait très évident que quelqu'un attaquait avant d'avoir eu de nombreuses occasions de deviner le mot de passe principal?

2. gardez un compte global/taux d'Échecs de connexion - c'est l'indicateur pour une attaque - pendant une attaque soyez plus strict sur les échecs de connexion par exemple ban IPs plus rapidement.

Je ne crois pas qu'il y ait une réponse parfaite mais je serais enclin à l'aborder sur la base d'essayer de confondre les robots si une attaque est détectée.

hors de mon esprit:

passez à un autre écran de connexion. Il a de multiples 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 des champs sont aléatoire --une clé de session est envoyée avec l'écran de connexion, le serveur peut alors trouver quels champs sont quoi. Réussissez ou échouez il est ensuite écarté de sorte que vous ne pouvez pas essayer une attaque de replay--si vous rejetez le mot de passe ils obtiennent un nouvel ID de session.

tout formulaire qui est soumis avec des données dans un mauvais champ est supposé provenir d'un robot--le login échoue, période, et que L'IP est étouffé. Assurez-vous que les noms de champ aléatoires ne correspondent jamais aux noms de champ légitimes afin que quelqu'un qui utilise quelque chose qui se souvient des mots de passe ne soit pas induit en erreur.

ensuite, Que diriez-vous d'une autre sorte de captcha: vous avez une série de questions qui ne causeront pas de problèmes pour un humain. Cependant, ils sont pas aléatoire. Quand l'attaque commence tout le monde est donné question #1. Après une heure, la question n ° 1 est écartée, ne plus jamais être utilisée et tout le monde reçoit la question n ° 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 il doit envoyer de nouvelles instructions à son botnet dans l'heure pour pouvoir faire quoi que ce soit.

puisque plusieurs personnes ont inclus CAPTCHA comme mécanisme de repli humain, j'ajoute une question plus tôt StackOverflow et fil sur L'efficacité de CAPTCHA.

L'utilisation de CAPTCHA ne limite pas les améliorations de votre étranglement et d'autres suggestions, mais je pense que le nombre de réponses qui comprennent CAPTCHA comme un repli devrait tenir compte de l'humain-basé méthodes à la disposition des personnes qui cherchent à briser la sécurité.

vous pouvez également réduire les gaz en fonction de la force d'un mot de passe utilisateur.

quand un utilisateur enregistre ou modifie son mot de passe, vous calculez une note de force pour son mot de passe, disons entre 1 et 10.

quelque chose comme "mot de passe" marque un 1 alors que "c6eqapRepe7et*Awr@ch" peut marquer un 9 ou 10 et plus le score est élevé, plus il faut de temps pour que l'étranglement se déclenche.

la première réponse que j'ai habituellement entendue en posant cette question Est de changer de 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 un simple balayage de réseau et les attaquants recourront aux recherches DNS. Ne lancez pas sur la même adresse que votre Apache(AAAA)/Sendmail(MX->AAAA)/ce que vous avez donné à tout le monde(AAAA). S'assurer que votre zone ne peut pas être xferd, attendre que vous autorisez votre zone à être téléchargée par quelqu'un?

si les bots trouvent votre serveur setup new hostnames, il suffit de prepend some gibberish to your hostnames, et de changer votre adresse. Laissez les anciens noms et même setup **les noms de pot de miel pour le réseau bot à timeout sur.

* * Testez vos enregistrements reverse(PTR) (sous ip6.arpa.) pour voir si elles peuvent être utilisées pour mettre à zéro dans on /4 qui ont des enregistrements VS /4 qui n'en ont pas. C'est-à-dire généralement ip6.arpa aurait ~ 32 "."dans une adresse, mais en essayant avec les derniers disparus pourrait elude les blocs de 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 parties de l'espace d'adresse.

dans le pire des cas, les utilisateurs devront configurer un tunnel IPv6, ce n'est pas comme s'ils devaient aller aussi loin que VPNing dans une DMZ... Si on se demande pourquoi ce n'est pas la première option.

aussi Kerberos est cool, mais IMHO LDAP souffle (Quel est le problème technique avec NISPlus? J'ai lu que Sun avait décidé que les utilisateurs voulaient LDAP et pour cette raison ils ont abandonné NIS+). Kerberos fonctionne très bien sans LDAP ou NIS, il suffit de gérer les utilisateurs sur une base hôte par hôte. L'utilisation de Kerberos vous donne une ICP facile à utiliser, sinon automatisée.

un peu tard ici, mais je pensais, en supposant un cas difficile - l'attaquant utilise beaucoup d'IPs aléatoires, des noms d'utilisateur aléatoires et un mot de passe aléatoire sélectionné à partir de dire une liste des 10.000 plus populaires.

une chose que vous pouvez faire, surtout si le système semble attaqué en ce sens qu'il y a beaucoup de tentatives de mot de passe erroné sur le système et surtout si le mot de passe est une faible entropie 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 ya une bonne chance qu'ils obtiendront beaucoup, mais leurs chances d'obtenir également les bons noms serait de réduire les succès de façon spectaculaire.