Discussion :

[psychoBob]

Bonjour,

Une question théorique à propos de la meilleur façon de protéger l'identification à un espace membre.
L'idée est classique, après 5 tentatives ratées, on bloque la possibilité de s'identifier.
J'ai fait cela personnellement:
- A chaque erreur j'envoie l'ip dans la table ipBloque.
- A chaque tentative je compte le nombre d'ip enregistrée dans la table ipBloque durant les 15 dernières minutes et similaires à celles du client.
- Si j'en trouve 5, le formulaire ne s'affiche plus.
- Au bout de 15 minutes, le formulaire s'affiche de nouveau.

Est-ce un bon système ? On m'a conseillé de le faire avec des sessions ? Qu'en pensez-vous ?
J'ai testé sur développez, à priori c'est basé sur l'IP et pas sur les sessions ni les cookies (je n'ai pas approfondi).

Aussi dans mon système, lorsque l'identification a échoué, et si il y a eu moins de 5 tentatives, la page suivante notifie l'erreur mais réaffiche automatiquement le formulaire au lieu d'afficher l'erreur sur une page spécifique nécessitant ensuite un retour pour réafficher le formulaire d'identification. C'est pratique pour le visiteur mais aussi pour un éventuel robot.
Qu'en pensez-vous ?


Voilà, j'attend vos remarques et suggestions

[Cr@zyDeep]

J'utilise le même genre de technique. Pour les sessions c'est inutile car il suffit que la personne ferme son navigateur pour la détruire. Pareil pour les cookies. Donc l'ip reste le meilleur choix.

Perso j'ai rajouté un champ recopier chiffre et lettre d'une image au bout d'un essai raté. Ca ne gène pas le visiteur pour l'authentification et ca evite tout type de robot (sauf si il décrypte l'image, mais bon ca frene deja pas mal).

[psychoBob]

Oui le truc des lettres à recopier après un essai raté est pas mal, mais dans l'immédiat je sais pas faire et ça me gave un peu. Eventuellement je peux rajouter une question stupide (de quelle couleur est le ciel quand il faut beau...?).

Pour les sessions, même s'il suffit de fermer la fenêtre à priori cela protège quand même contre les attaques de type force brute. Par contre ça peut ne pas faire sérieux vis à vis du client, mais normalement le vrai client ne ratera pas 5 fois.

Pour les IP, je me demande si ce n'est pas un problème, peut être pas pour les proxys, mais par exemple pour les cas comme les utilisateurs d'aol qui changent souvent d'ip.

[Cr@zyDeep]

Dans tout les cas leur changement d'ip est superieur à 15 min donc c'est ce qui à de mieux. Aprés pour les sessions tout dépend de ton hébergement, car il y en a qui passe par les cookies donc assez facile de ne pas se faire tracer.

Pour générer une image c'est tellement facile que je te le mets au cas ou.
<?
session_start();
function rvb2dec($c)
{
global $r,$v,$b;
$c[0]=='#'?$d=1:$d=0;
$r=hexdec($c[$d++].$c[$d++]);$v=hexdec($c[$d++].$c[$d++]);$b=hexdec($c[$d++].$c[$d]);
}

$key=$_SESSION['key'];
header("Content-Type: image/gif");
$i=@imagecreate(80,18) or die("Impossible d'initialiser la bibliothèque GD");
rvb2dec("FFFFFF");
$background=imagecolorallocate($i,$r,$v,$b);
rvb2dec("000000");
$color=imagecolorallocate($i,$r,$v,$b);
imagestring($i,5,14,4,$key,$color);
imagegif($i);
imagedestroy($i);
?>

Tu mets ca dans un fichier gen_image.php puis aprés tu mets dans ton code <img src="gen_image.php"> en aillant défini une clé par $_SESSION['key']

La parade est vraiment intéressente pour le peu de temps à le mettre en place.

[psychoBob]

Dans tout les cas leur changement d'ip est superieur à 15 min donc c'est ce qui à de mieux.

Tu parles des utilisateurs d'AOL là ? Comment tu sais ça si c'est la cas ? Je ne l'ai lu nulle part.

Ok pour ton code, je viens de le sauvegarder avec ton commentaire, ça pourra m'éviter de chercher le cas échéant, merci.


Je viens de me rendre compte d'un truc en vérifiant mon script :
j'enregistre les ip en cas d'échec. Au 5 ème je bloque le formulaire. Pour ça je vérifie si dans les 15 dernières minutes il n'y a pas eu 5 ip identiques enregistrées.
Donc en fait ça ne bloque pas vraiment pour 15 minutes : Si le gars se trompe à 10h00, recommence à 10h05 puis à 10h08 puis à 10h12, puis à 10h16, il n'est pas bloqué car la première tentative à 10h00 n'est plus comptabilisé.
C'est un peu foireux, il faudrait rajouter un champ pour stocker l'ip bloquée et vérifier si dans les 15 dernières minutes cette ip n'a pas été stockée après 5 tentatives foireuses.
Mais bon je crois que de toute façon mon système bloque très bien les risques d'attaque par force brute. Je me trompe ?

[Cr@zyDeep]

Pour tout les FAI, free aussi change d'ip régulierement, mais je doute qu'il change d'ip moins que toute les 15 min.
Perso j'ai fait tout autrement. En faite j'enregistre l'ip en cas de mauvaise identification puis je lui associ un nombre d'erreur que j'incremente a chaque fois, tout en mettant a jour le datetime. Puis au bout de 3 essai je bloque l'ip 1 heure. Mais sinon ton script bloquera les brute force à condition qu'il n'utilise pas un tempo de 3 min car 3x5=15min mets peut être moins d'essai ou banni plus longtemps si tu veux plus de sécurité.

[psychoBob]

Ton idée est pas mal du tout Cr@zyDeep, je vais voir pour la reprendre si j'ai une heure à y passer, c'est mieux que mon truc un peu bancal.

Sinon, tu penses vraiment qu'un logiciel de force brute peut casser quelque chose si il est programmé pour effectuer une requête toutes les trois minutes ? (Ce qui serait quand même pas de pot, mais là n'est pas la question.)
Parce qu'avec un passe à 9 lettres, ça va lui prendre un sacré bout de temps je pense, non ?

Je reprend une autre question du début, j'aimerais bien savoir :

Aussi dans mon système, lorsque l'identification a échoué, et si il y a eu moins de 5 tentatives, la page suivante notifie l'erreur mais réaffiche automatiquement le formulaire au lieu d'afficher l'erreur sur une page spécifique nécessitant ensuite un retour pour réafficher le formulaire d'identification. C'est pratique pour le visiteur mais aussi pour un éventuel robot.
Qu'en pensez-vous ?

Vaut-il mieux afficher une page d'erreur qui force le retour pour réobtenir le formulaire, ou bien le fait de réafficher automatiquement le formulaire(avec un message d'erreur) ne pose pas de problème ?

[ShinJava]

Vaut-il mieux afficher une page d'erreur qui force le retour pour réobtenir le formulaire, ou bien le fait de réafficher automatiquement le formulaire(avec un message d'erreur) ne pose pas de problème ?

Je pense qu'il est quand même plus simple de reafficher le formulaire avec le message d'erreur. C'est beaucoup plus simple et plus facile pour le visiteur.
Maintenant pour le robot ca ne changera pas grand si tu rajoutes un lien qui lui demande de revenir. Il lui suffit tout simplement de fermer la fenetre apres son echec et reouvrir une fenetre à la page du formulaire. Ca se trouve, les robots qui reviennent en arriere automatiquement ca doit deja exister.
Même mieux, un robot qui apres chaque echec, remet l'URL du formulaire dans la barre d'adresse... (faudra demander confirmation au pro et ceux qui ont deja eu à faire à ca).

En tout cas, cette discussion est interessante.

++
ShinJava

[psychoBob]

Bon alors ta réponse m'arrange, à défaut d'être absolu certain, elle me donne bonne conscience... doute pour doute hein...
En tout cas je viens de reprendre tout le script pour faire comme Cr@zyDeep, c'est effectivement plus logique et en plus ça évite de stoker 5 fois trop de tuples.

[Cr@zyDeep]

Pareil il n'y a aucun interet de les renvoyer sur une autre page, ca gène le visiteur et ca ne protège pas plus. En fait un brute force c'est trés facile à faire et généralement tu le personnalises en fonction du site, sauf si c'est un CMS. Donc oui tu peux le tempo à 3 min et la redirection ne gène en rien, je dirais même que ca simplifi le travail car tu n'as pas besoin de vérifié le contenu de la page pour savoir si tu es logué, mais il faut juste vérifié la redirection.
Maintenant tout est relatif, tu ne peux pas rendre un système inviolable, tu adapte le niveau de sécurité en fonction des besoins et avec les solutions que nous avons ennoncés il y a quand même de quoi faire fuir pas mal de personnes.
Mais sache qu'une attaque bruce force est généralement une des dernières méthode utilisé, car elle est trés lourde et lente.