Le MD5 une valeur sur ?

[Joe]

Utiliser sur beaucoup de CMS , la protection de chiffrage MD5 est-elle vraiment sur ?

Est-il évident pour un administrateur une personne mal attentionné accédant a la bdd de sortir nos mot de pass en clair ?

[ark]

Il y a actuellement beaucoup de base de données regroupant des mots de passes stockés sous leur forme hashée en md5. Il est donc assez facile de retrouver un mot de passe "simple".

[Mazaki]

Ouai, avec un salt.

[0pc0deFR]

A savoir que plusieurs mots de passe peuvent avoir le même hash MD5. C'est le principe de la collision MD5: http://www.mathstat.dal.ca/~selinger/md5collision/ pour l'exemple (avec des fichiers). Il existe aussi (comme mentionné par Ark) des bases de données appelées Rainbow Table. Ensuite, de très bons outils existent pour casser les hashs MD5 par brute force très souvent déporté sur le GPU (Processeur graphique). John the Ripper est un bon exemple (bien que par déporté sur le GPU il me semble). Pour ce qui est du GPU le plus connu doit être BarsWF: http://3.14.by/en/md5.

En espérant avoir apporté des éléments de réponse.

[gruik]

http://fr.wikipedia.org/wiki/MD5#Cryptanalyse
on peut notamment y lire "La sécurité du MD5 n'étant plus garantie selon sa définition cryptographique, les spécialistes recommandent d'utiliser des fonctions de hachage plus récentes comme le SHA-256.

[Joe]

Merci pour ces infos utiles

[notfound]

Ceci étant, si tu y mets ton grain de salt, je pense que MD5 devient bien meilleur !

[Ekroz]

Sur un mot de passe faible, l'utilisation du salt permet de diminuer les risques de bruteforce.
Cependant sur un mot de passe plus compliqué, en faite ça ne diminuera pas le risque puisque celui-ci est égal au maillon le plus faible de la chaîne, donc le risque de collisions.
Personnellement pour sécuriser les mots de passe sur mon site, j'utilise plusieurs techniques :

1) Je détecte l'algorithme disponible sur le serveur qui produit le plus long hash et donc qui a le plus haut potentiel de sécurité (bon il doit y avoir une différence entre SHA-512 et Whirlpool mais trop minime à échelle humaine). Comme ça le script peut être utilisé n'importe où et pendant une durée illimitée, il évoluera de lui même.
2) Je génère deux grains de sel aléatoires (début et fin du mot de passe).
4) Je hashe le mot de passe, et enregistre tout ça dans la DB (hash, algo, salt1, salt2).

Code PHP :

<?php
/**
 * Fonction qui retourne le hash le plus long (et donc celui qui a le moins de
 * possibilité de collisions).
 */
function getBestAlgo()
{
    $bestAlgo = array(
        'algo' => '',
        'len' => 0
    );
    
    $algos = hash_algos();
    
    foreach ($algos as $algo) {
        $hash = hash($algo, '');
        $len = strlen($hash);
        
        if ($len > $bestAlgo['len']) {
            $bestAlgo['algo'] = $algo;
            $bestAlgo['len'] = $len;
        }
    }
    
    return $bestAlgo['algo'];
}

$pwd = 'myLittlePony';

/**
 * On génère deux graines aléatoires.
 */
$rand1 = mt_rand();
$rand2 = mt_rand();

/**
 * Données à enregistrer dans la DB.
 */
$algo = getBestAlgo();
$salt1 = uniqid($rand1);
$salt2 = uniqid($rand2);

/**
 * Génération du hash à enregistrer dans la DB.
 */
$pwd = $salt1 . $pwd . $salt2;
$hash = hash($algo, $pwd);

/**
 * Affichage du hash.
 */
echo $hash;
?>

Et bien évidemment sur le formulaire de connexion, on utilise un captcha et on autorise que 3 tentatives par adresse IP de se connecter avant de bannir pendant 5 minutes le malotru qui a osé s'attaquer à un administrateur soucieux de sa sécurité sans oublier d'envoyer un mail automatique avec un maximum d'informations sur l'incident : compte concerné, mot de passe essayé (pour voir si c'est une erreur, une injection ou du spam), les en-têtes HTTP (pour voir si c'est un humain, un script ou un bot), la géolocalisation (si c'est la vengeance de quelqu'un qu'on connait, du moins ça marche si on connait quelqu'un qui habite dans un petit bled) etc...

[Luxerails]

4) Je hashe le mot de passe, et enregistre tout ça dans la DB (hash, algo, salt1, salt2).

Le but n'est pas que le hacker ne puisse pas retrouver le clair du hash ?
Si il arrive à accéder à la base de données, et qu'il tombe sur le hash mais qu'il ne connaît pas le salt, c'est beaucoup plus difficile pour lui.
Mais si le salt est stocké dans la bdd avec le hash je vois pas trop l'intérêt du salt...

[Dobry]

Il faut que le salt reste toujour le même afin d'identifier l'utilisateur correctement, donc il faut forcement le conserver quelque part, ou alors le créer dynamiquement à partir d'une donnée étant constante (le pseudo, si on considère qu'il ne peut être changé), dans ce cas, même avec l'acces à la base de donnée, le pirate ne connait pas l'algo de création du salt.

[Ekroz]

Le but n'est pas que le hacker ne puisse pas retrouver le clair du hash ?
Si il arrive à accéder à la base de données, et qu'il tombe sur le hash mais qu'il ne connaît pas le salt, c'est beaucoup plus difficile pour lui.
Mais si le salt est stocké dans la bdd avec le hash je vois pas trop l'intérêt du salt...

L'intérêt du salt est de casser l'utilisation des rainbow tables, sinon t'auras beau utiliser du SHA-512 ça sera inutile.
A l'heure où les doubles coeurs, CUDA et les disques durs de 1 To sont démocratisées, il devient du niveau de n'importe quel bidouilleur qui s'y connait un minimum en programmation et en réseau de se faire son petit réseau de calcul distribué.
Peu importe la qualité du salt, qu'il soit connu ou pas, aléatoire ou prédéfini, l'idée c'est de changer complètement la structure du condensat pour éviter de le retrouver dans une rainbow table.

[Luxerails]

Peu importe que le salt soit connu ou pas, en effet les rainbow tables seront inefficaces.
Par contre le brute-force lui le reste... sauf avec un salt inconnu par le hacker et assez grand.

ou alors le créer dynamiquement à partir d'une donnée étant constante

Je trouve que c'est une excellente idée

[0pc0deFR]

A savoir qu'il existe maintenant des outils de création de malwares (type Rat's ou botnet's) qui propose des fonctions pour casser des mots de passe. L'idée est simple, avec une rainbow table, le C&C envoi X nombres de possibilités à chaque machines qui vont les tester et retourner le résultat au C&C et pour le brute force, plusieurs machines vont brute forcer le mot de passe simultanément sachant que le risque de tester deux fois le même mot de passe est très petit et même si c'était le cas ça n'aurait pas de conséquence sauf une toute petite perte de temps qui au final est compensé par le grand nombre de machine en attaque sur un même hash. Avec ce principe, plus aucun mot de passe n'est en sécurité du fait qu'on a tous de grosse machine (ou des machines correct du moins). Avec un réseau de botnet correct, il serait assez simple de casser à peut près n'importe quel hash. Plus le nombre de possibilités est grand plus ce sera long mais au final un cluster qui répond à une action (de calcul) sera toujours plus efficace qu'un simple machine qui répond à cette action.