Comment Brute-Forcer sait-il que le mot de passe est craqué pour le nom d'utilisateur cible?
Il existe de très nombreuses attaques par force brute (principalement pour le nom d'utilisateur 'admin') sur les sites WordPress. Toutes ces attaques se font automatiquement via des requêtes post.
La question 1: comment brute-forcer sait que le mot de passe est craqué pour le nom d'utilisateur cible?
Les brute-forcer essaient les mots de passe typiques tels que: '12345', 'qwerty' etc. Et souvent les administrateurs du site ont un nom d'utilisateur 'admin' avec un mot de passe typique et ce nom d'utilisateur est parfois craqué via brute-force. Plugin de tentatives de connexion limitées résolvez ce problème plutôt bien en passant.
L'idée et la question 2: si nous savons avec certitude qu'il s'agit d'une attaque par force brute (javascript-test ou cookie-test résolvent ceci parce que les brute-force-bots ne sont pas des clients de navigateur habituels) than est-il une bonne approche de ne rien dire du tout à Brute-Forcer même si le mot de passe est choisi correctement?
Discussion sur le forum WordPress.org .
Mise à jour: J'ai développé un plug-in de protection de la sécurité. Le plugin ajoute un cookie sur l'écran de connexion et vérifie si ce cookie existe dans la demande POST. Si le cookie n'existe pas, il s'agit d'une demande de force brute et la tentative de connexion est bloquée même si le nom d'utilisateur et le mot de passe sont corrects. Le plugin envoie de faux cookies de connexion WordPress au bot brute-force et le redirige vers la section admin pour émuler que le mot de passe est déchiffré et que de nombreux brutaux forcent leurs attaques par la suite. C'est vraiment génial :)
Les informations d'identification de connexion sont traitées dans wp_signon() et, si elles sont valides, wp_set_auth_cookie() enverra un cookie dans le corps de la réponse HTTP.
Le nom de ce cookie est défini dans une constante nommée SECURE_AUTH_COOKIE ou AUTH_COOKIE. Les deux noms commencent par wordpress_.
Mais ils n’ont pas à le faire. Vous pouvez définir ces constantes dans votre wp-config.php et ajouter une couche d’obscurité afin que l’attaquant ne sache pas vraiment s’il s’agit du cookie standard.
Vous pouvez ajouter une autre couche: connectez-vous à l'action 'wp_login_failed' et envoyez un cookie qui commence réellement par wordpress_. Vous pouvez le nommer wordpress_logged_in par exemple. Il ne fait rien et ne rendra pas votre blog mesurable plus sûr … mais cela ne fait pas de mal.
D'autre part: WordPress enverra un en-tête location et redirigera l'utilisateur après la connexion à une autre page. C’est facile à détecter et plus difficile à contourner.
Une vérification supplémentaire que j'utilise maintenant sur de nombreux sites: Ajoutez une nouvelle case à cocher au formulaire de connexion par JavaScript avec un nom unique par site et demandez-lui de le cocher. Si cette case n'est pas cochée, la réponse sera toujours une page vierge même si le mot de passe est correct . Vous pouvez l'obtenir auprès de GitHub: Champ de connexion unique T5 .
est-ce une bonne approche de ne rien dire du tout au brut, même si le mot de passe est choisi correctement?
Non, cela ne fera aucune différence pour le pirate informatique sophistiqué, et pour le propriétaire du site, il en sera de même s'il peut être piraté 10 fois par script kiddies ou une fois par un pro.
comment brute-forcer sait que le mot de passe est craqué pour le nom d'utilisateur cible?
Si je faisais de telles choses, j'essaierais simplement d'accéder à examle.com/wp-admin et de vérifier si je suis redirigé vers la page de connexion.
Quoi qu'il en soit, votre hypothèse selon laquelle les utilisateurs se connectant uniquement à partir de navigateurs est fausse. À partir de la version 3.5, XML-RPC est activé par défaut et vous n'avez besoin ni de JS ni de cookies pour vous connecter. Toute modification apportée à la manière dont XML-RPC fonctionne endommagera probablement toutes les applications de publication utilisant le protocole.
Vous regardez ce problème du mauvais point de vue. Tout ce que vous ferez empêchera efficacement un bot d’essayer de vous connecter à votre compte empêchera également un utilisateur général. Tout ce qu'un humain peut faire, un programme bien écrit peut aussi le faire (et le faire plus rapidement). Un cookie valide doit être envoyé en cas de connexion réussie et il est facile pour un programme de vérifier si un cookie renvoyé est valide ou non, même si vous envoyez des cookies factices en cas d’échec ou une approche similaire.
Cela dit, une solution très efficace pour empêcher les tentatives de connexion par force brute consiste à utiliser un plug-in empêchant plus de x nombre de connexions dans un laps de temps donné. Limiter les tentatives de connexion est un plugin agréable utilisé par beaucoup de gens et qui le fera pour vous (et votre question suggère que vous avez déjà envisagé cette option).
La limitation du nombre de tentatives de connexion empêchera la force brute, car aucun utilisateur n'essaiera de se connecter 100 fois de suite s'il est le véritable utilisateur, mais un bot essaiera des milliers de fois. Tout mot de passe décent sera complètement impossible à craquer au cours de la vie si vous limitez le nombre de tentatives à 5 par heure (ou tout autre nombre raisonnable).
Je sais que cela ne répond pas tout à fait à votre question, mais j'espère que cela vous donnera une meilleure direction.
Bonne chance!