Le HASH MD5 est une fonction irréversible, il n'existe pas d'algorithme ou de fonction permettant de retrouver la chaîne d'origine à partir de son HASH.

.

J'ai pas tout suivi, vous êtes bien trop verbeux pour mon dimanche tranquille. Mais j'ai l'impression qu'on à pas encore parlé de ceci:

On peut utiliser un hash le plus performant qui soit, si on utilise un mot de passe de quelques lettres, ou un mot courant (ie: qui se trouve dans le dico), ou un assemblage facilement trouvable via du social engineering, ben peu importe l'algo. Peu sont les cas, sur le web, d'attaque brute-force. Les attaques par dico sont bien plus vicieuses et efficaces.

Le brute-force s'appliquerait dans les cas ou on obtiendrait, d'une façon ou une autre, le hash du mot de passe: alors, c'est facile de lancer une brute sur le hash, sur un poste qui fera des millions d'essais par seconde (le web est un peu trop lent pour ça).

En plus, un hash md5 n'est pas unique, il est possible de trouver un texte différent de l'original mais qui donne le même hash.

Tout est la: la.

Les attaques par dico sont des attaques brute-force, c'est là même chose, c'est juste l'algorithme de recherche du mot de passe qui change. Du point de vue de la soumission du mot de passe, on s'en fout si l'attaque se fait par dico ou non…

Ensuite, concernant MD5, évidemment si on a le hash du mot de passe c'est trivial. Tu prends une db de mots de passe sur internet et tu fais une simple requête pour retrouver un mot de passe correspondant au hash. Mais là le problème est là aussi indépendant de ça. Si quelqu'un réussit à choquer le hash des mots de passe utilisateur, c'est qu'il a pu infiltrer le système, et là les restrictions de sécurité au niveau serveur http sont juste useless.

Il ne faut pas mélanger les niveaux de sécurité (si l'un d'eux est compromis, les suivants sont inutiles) :
- Sécurité et stabilité du système, mise en oeuvre par l'administrateur du serveur, ça comprend protection contre les DoS, mises à jour de sécurité, définition des droits utilisateurs.
- Sécurité du site, mise en oeuvre par le développeur, protection contre les injections de code, fix des failles du site.
- Sécurité de la procédure de connexion, mise en oeuvre par le développeur, qui est tout aussi bien la sécurité du protocole client-serveur, que les mécanismes de protection contre le brute-force.
- Sécurité de la représentation du mot de passe. Théoriquement, si les sécurités précédentes étaient bien appliquées, ça ne devrait pas être utile, mais on tient à protéger la vie privée des utilisateurs, notamment leurs mots de passe, donc il faut chiffrer le mot de passe autrement mieux qu'avec un simple MD5…
- Enfin sécurité du mot de passe, qui est de la responsabilité de l'utilisateur. Celle de ne pas prendre un mot de passe trivial, donc pas de mot du dico, pas de mot de passe court, pas de mot de passe alphanumérique, …

Et je dois en oublier encore, vu que je ne suis pas un expert. La sécurité c'est pas un domaine simple non plus, et là on s'amuse un peu à tout confondre, aussi bien la sécurité du serveur, que la sécurité du mot de passe, etc… Alors que ce ne sont ni les mêmes mécanismes, ni les mêmes enjeux, ni les mêmes acteurs pour les mettre en oeuvre, etc…

Les attaques par dico sont des attaques brute-force, c'est là même chose, c'est juste l'algorithme de recherche du mot de passe qui change.

Non. Une attaque par force brute est par définition une attaque exhaustive. Une attaque par répertoire de mots (dico, noms, villes..) par définition pas.

Du point de vue de la soumission du mot de passe, on s'en fout si l'attaque se fait par dico ou non

Techniquement, c'est sur. Dans les faits, l'un donnera un résultat en peut-être quelques heures, l'autre en quelques siècles.

Si quelqu'un réussit à choquer le hash des mots de passe utilisateur, c'est qu'il a pu infiltrer le système

Dans un cas récent, un gus avait obtenu le hash du mot de passe d'un autre gus parce que cet autre gus c'était inscrit sur un forum géré par le premier gus. Donc non, ça ne veut pas dire qu'il à infiltré le système, juste que gus numéro 2 utilisé le même mot de passe à plusieurs endroits, comme tout le monde.

moi c'est pire jsuis breton...

A là là ...

Je sais ce que c'est , ma petite amie a des souches bretonne ...

... de ce fait , ce n'est jamais moi qui décide du programme tv à la maison ...

Heureusement que je n'aime pas la TV ...

Ouh, ya du pinaillage là…

Les attaques par dico sont des attaques brute-force, c'est là même chose, c'est juste l'algorithme de recherche du mot de passe qui change.

Non. Une attaque par force brute est par définition une attaque exhaustive. Une attaque par répertoire de mots (dico, noms, villes..) par définition pas.

Merci de jouer sur les mots…

Si quelqu'un réussit à choquer le hash des mots de passe utilisateur, c'est qu'il a pu infiltrer le système

Dans un cas récent, un gus avait obtenu le hash du mot de passe d'un autre gus parce que cet autre gus c'était inscrit sur un forum géré par le premier gus. Donc non, ça ne veut pas dire qu'il à infiltré le système, juste que gus numéro 2 utilisé le même mot de passe à plusieurs endroits, comme tout le monde.

Oui, mais dans ce cas le problème ne vient pas du hashage. Je ne vois pas comment tu peux utiliser cet exemple. Que l'on code sur un site les mots de passe de telle ou telle manière n'influe en rien le fait qu'un administrateur d'un autre site détourne ses mots de passe. En effet, ça n'a rien d'une infiltration de ton système, mais ça n'a rien d'un piratage de ton site non plus.
Par ailleurs sur l'autre site, c'est pareil, même si les mots de passe sont chiffrés dans un format illisible, je ne vois pas ce qui empèche l'administrateur de désactiver le chiffrage.
Dans les deux cas, ça n'a absolument rien à voir avec un problème de sécurité de ton site. C'est simplement du social engeneering. L'administrateur d'un site est un tier de confiance, quand tu t'inscris sur ce site, tu lui fournis directement le mot de passe, tu supposes qu'il ne le détourneras pas. Et là c'est l'utilisateur qui est en tort, c'est lui qui a fait confiance à la mauvaise personne, en fournissant une information critique (un mot de passe) à une personne qui n'était pas de confiance.
Donc je persiste, le hashage des mots de passe est totalement useless sur un environnement sécurisé. Si les autres sécurités sont remplies, si personne ne réussit à infiltrer le système ou trouver une faille dans le site, personne ne réussira à accéder à la manière dont sont stockés les mots de passe.

Merci de jouer sur les mots…

Mais pas du tout, la définition dépend du point de vue qu'on adopte. Et un point de vue n'est pas meilleur qu'un autre: il faut justement en avoir plusieurs pour pouvoir cerner la problématique dans son entier. On a juste eu tort de dire que l'autre avait tort.

Et si je parlais du social engineering (alors qu'on parle de solutions techniques de protéger un site contre des intrusions), c'est pour démontrer le côté relatif de la chose. Si ton client utilise son propre prénom comme mot de passe, tu ne pourras pas l'en empêcher (à moins d'avoir recours à une série de critères bien lourdingues comme dans server 2008). Le principe du mot de passe est vicié à la base (mais c'est mieux que rien).

Sinon, pourquoi ne pas utiliser une authentification type OpenID?

Je crois que la meilleure sécurité est d'éteindre le serveur. Vous me suivez Bon je retourne à ma bouteille

Salut,
Comme seule les imbéciles ne chage pas d'avis, et moi j'étais borner sur une piste, je prend bonne notes des infos du poste donc j'ai recoder mon espace connexion enfin la partie qui vérifie les ip$j'ai fais ceci

$date_tentative  = date('Y-m-d');
$date_debut_verif = date("Y-m-d", strtotime("-1 day"));                      //-->Date courante - 1 jour.--//
$heure_tentative = date('HH:MM:SS' );                                        //-->Heure courante.--//
$ip_visiteur     = $_SERVER["REMOTE_ADDR"];                                  //-->Adresse IP.--//
$nbr_autho_tentative = '30';                                                //-->Nombre de tentative authoriser avant expulsion.--//
$adr_redirection = 'http://www.google.com';                               //-->Adresse de redirection, en cas d'expulsion.--//


   $sql_ip = "INSERT INTO verif_ip
   			  SET
   			  id_ip = '',
   			  ip    = '" . $ip_visiteur . "',
   			  date_connect = '".$date_tentative."',
   			  heure_connect = '".$heure_tentative."'";

   			  $result = mysql_query($sql_ip) or die("Erreur MySQL : Impossible de sauvegarder les données");





	 $sql_verif_ip = "SELECT COUNT(ip)AS nbr_ip,ip
	                 FROM verif_ip
                     WHERE date_connect BETWEEN '" . $date_debut_verif . "' AND '" . $date_tentative . "'
	                 GROUP BY ip
	                 ORDER BY date_connect ";
                    //WHERE date_connect BETWEEN '" . $date_tentative . "' AND '" . $date_debut_verif . "'

					 $result = mysql_query($sql_verif_ip) or die("Erreur MySQL : Impossible de lire les données");

                     while($row_ip = mysql_fetch_array($result))
                      {

	                       if($row_ip['nbr_ip'] >= $nbr_autho_tentative)
	                       	{
		                       	echo '<font color="#FF0000">Erreur !</font><br>';
		                       	echo 'Trop de tentatives pour l\'ip : ' . $row_ip['ip'].'<br>';
		                       	echo 'Nombre de tentatives autorisées : '.$nbr_autho_tentative .'.<br> Nombre de tentatives réalisées : '.$row_ip['nbr_ip'].' . ';
		                        //sleep(5);
		                        $ejection = ($row_ip['nbr_ip'] >= $nbr_autho_tentative + 10) ? header("Location:".$adr_redirection) : '';
		                        echo $ejection;
		                        exit();
	                       	}

Donc juste avant de vérifier les données login et passe je vérifie l'ip si dans les 24Heures elle es tplus de 30x dans ma table je la bloque.
Alors ma questions :
Comment améliorer mon script.

Il te faut exécuter la requête de comptage seulement pour l'IP du visiteur en cours, donc rajouter une condition dans le WHERE :

     $sql_verif_ip = "SELECT COUNT(ip)AS nbr_ip,ip
                     FROM verif_ip
                     WHERE date_connect BETWEEN '" . $date_debut_verif . "' AND '" . $date_tentative . "' 
                      AND ip = '" . $ip_visiteur . "'
                     GROUP BY ip
                     ORDER BY date_connect "; 

Il te faut exécuter la requête de comptage seulement pour l'IP du visiteur en cours, donc rajouter une condition dans le WHERE :

     $sql_verif_ip = "SELECT COUNT(ip)AS nbr_ip,ip
                     FROM verif_ip
                     WHERE date_connect BETWEEN '" . $date_debut_verif . "' AND '" . $date_tentative . "' 
                      AND ip = '" . $ip_visiteur . "'
                     GROUP BY ip
                     ORDER BY date_connect "; 

A bin oui idiot que je suis, sans compter l'ip du visiteur une fois qu'une ip est inscrit plus de 30 fois plus personne ne rentre quoi que finalement
Je plaisante merci j'avais pas vue cette erreur

Je sais pas si c'est une mauvaise chose de bloquer le serveur s'il y a trop de tentatives de connexion, quitte à donner des adresses IP "passe droit". Mais bon, la le seuil serait plutot 300 ou 400.

Enfin, ca dépend de la taille du site. Si le site est prévu pour que trop pelerin se connecte une fois le 36 du moi, cette condition ne sera pas trop restrictive. Si c'est pour un forum du type PHPFrance, c'est autre chose...

Je sais pas si c'est une mauvaise chose de bloquer le serveur s'il y a trop de tentatives de connexion, quitte à donner des adresses IP ...

Avec la même ip

Non, je parle bien toute IP confondu.

Si ton site dois recevoir à pe près une petite centaine de visiteur toute les heures et si tu as 200 connexions ratés dans l'espace de dix minutes, quelques soient les IP d'où viennent les requètes, c'est bien que tu est en train de te faire attaquer. Donc tu ferme la porte

Et tu organises toi même un déni de service…
Ce n'est pas une solution viable. Pour se protéger, la pire solution pour un service est de couper (cela revient à la solution de protection universelle, la machine la mieux protégée est la machine éteinte et déconnectée).

Il est vraiment très important de mettre en place des solutions qui n'influent pas sur le service, sans quoi on ouvre d'autres failles de sécurité…