login et bruteforce

[php_addict]

Bonjour

je lance ce topic pour un petit débat sur les tentatives de récupération de mot de passe utilisateur par bruteforce.

Comment gérez vous les tentatives de récupération de mot de passe ?

Personnellement je pense faire un truc un peu étrange: laisser faire le boulot par le firewall iptable+fail2ban de mon serveur dédié, c'est à dire:

- chaque tentative de connexion est loggée dans une table
- au bout de X tentatives échouées, je redirige vers une url qui n'existe pas et c'est alors que se déclenche le firewall du serveur qui a une règle précise: au bout de X requetes HTTP vers des urls qui n'existe pas, l'ip de l'utilisateur est automatiquement bannis pendant X secondes. et après X secondes l'ip redevient autorisée.

Est il judicieux de procéder de la sorte? ou alors mieux vaut il que je code mon propre système de bannissement des ip...

Le soucis est que si l'ip provient d'une fac ou d'un poste de travail d'une entreprise c'est embêtant...

anti bruteforce ou pas?

PS: je sais bien que l'ip n'est pas une donnée fiable, mais je pense que c'est nécessaire d'essayer de bloquer les mauvais hacker, non ?

[niahoo]

Comment tu fais ta redirection vers ton URL inexistante ?

[php_addict]

Comment tu fais ta redirection vers ton URL inexistante ?

header php

header('Status: 301 Moved Permanently', false, 301);

header('Location: fake_url.php');

exit();

[ThErOr]

Le brute force tombe à l'eau si chaque test de mot de passe est entrecoupé de 20 minutes voir plus de "bannissement" de connexion. Il faudra beaucoup trop de temps (plusieurs années) pour tester un nombre important de mot de passe.

Ta détection et ton blocage peuvent se faire de manières différentes j'imagine, le log dans une table à chaque connexion erronée est suffisant à mon goût. Tu peux imaginer une règle plus en amont si l'activité d'un IP est vraiment trop suspecte tu peux la bannir au niveau du serveur HTTP directement...mais ca me parait difficile à automatiser.

Par contre je ne redirigerai pas vers une page de mon site mais vers un site extérieur, ou un site inexistant pour éviter de charger le serveur HTTP d'une autre requête. Le bannissement peut être utilisé également pour d'autres usages que la connexion. Cela peut être effectué sur une règle de tant de connexions HTTP par secondes/minutes...

[Viciousity]

Bah mettre au point de telles chose quand tu n'as pas encore 1000 joueurs n'est pas vraiment pertinent je trouve.
Surtout que les hackers s'adaptent à cela ...
En effet, j'ai lu un article (en anglais) qui expliquait pourquoi adopter la technique de stockage des données machine (carte graphique, processeur, etc ...) plutôt que l'IP. Et oui, les bon hacker mettent en place un système de roulage d'IP. Du coup des principes de sécurité comme le tien tombent à l'eau ...

[ThErOr]

C'est sûr que c'est pas non plus hyper secure, mais ça te permet d'éviter quelques inconvénients avec le petit hacker du dimanche et quand tu as comme tu le dis un petit traffic tu n'es confronté qu'à ce genre de hacker à mon avis

[niahoo]

Comment tu fais ta redirection vers ton URL inexistante ?

header php

header('Status: 301 Moved Permanently', false, 301);

header('Location: fake_url.php');

exit();

Et bien, disons que si je devais programmer un bot de bruteforce, je ne pense pas que j'implémenterai une fonction pour suivre les redirections, donc pas très utile le truc !

[Ieyasu]

Je préfère bloquer le compte avec un timestamp que je rajoute sur la table de connexion, sur lequel je fais une vérification avant chaque tentative.
Quelque soit l'ip ou la machine, si un joueur tente une connexion en force sur le même compte, il se prend un ban de X secondes.

Dans le cas d'une tentative de forçage d'un couple aléatoire login / pass un captcha suffit à ralentir suffisamment le coquin pour le dissuader d'accumuler les tentatives.

Facile et rapide à mettre en place.

[php_addict]

En effet, j'ai lu un article (en anglais) qui expliquait pourquoi adopter la technique de stockage des données machine (carte graphique, processeur, etc ...) plutôt que l'IP.

oui il s'agit en fait de la signature numerique de ton navigateur: c'est à dire toutes les infos que JS et capable de recolter sur ta becane: navigateur, resolution, police installées, plug in, etc...tu collecte toutes les infos et tu les stocke dans un md5 par exemple..c'est quasiment une signature unique de ton navigateur mais il faut que JS soit activé et les hacker ne passe pas par un navigateur pour le bruteforce donc c'est à mon avis pas mieux que l'ip...

Je préfère bloquer le compte avec un timestamp que je rajoute sur la table de connexion, sur lequel je fais une vérification avant chaque tentative.
Quelque soit l'ip ou la machine, si un joueur tente une connexion en force sur le même compte, il se prend un ban de X secondes.

Dans le cas d'une tentative de forçage d'un couple aléatoire login / pass un captcha suffit à ralentir suffisamment le coquin pour le dissuader d'accumuler les tentatives.

Facile et rapide à mettre en place.

je n'avais pas pensé au captcha, je me suis dis qu'avec ce systeme de bloquer un compte si trop de tentative alors tu peut facilement bloquer tout les comptes du jeu...mais avec un captcha ca me semble une bonne idee

je ne pretends pas avoir autant de succes pour avoir ce genre de probleme mais qui sait, il y toujours des petits malins...je le vois bien aux nombre de tentatives de recherche de faille sur mon dédié (scan des url comme phpmyadmin, ou bien bruteforce de l'entree ssh, et pourtant mon serveur est un tout petit serveur...)

[Jeckel]

De mon côté j'ai fait assez simple, au bout de X échecs de mot de passe (paramétrable en administration) le compte utilisateur est verrouillé.

Deux solutions pour déverrouiller son mot de passe :
- par un administrateur
- en réinitialisant le mot de passe (avec envoie d'une clé par mail)

Celui qui voudra hacker le compte devra d'abord avoir accès à la boite mail de l'utilisateur.