Chiffrement et hash en PHP contre l'attaque Man in the middle

Le hash est un procédé de chiffrement irréversible. Ceci implique qu'on ne peut appliquer la transformation inverse, et qu'on ne peut donc que comparer les hashs entre eux. L'avantage est que personne, y compris le webmaster, n'a accès aux mots de passe des membres.

Il existe deux principaux algorithmes de hash, le MD5 et le SHA1.

Le MD5 est déprécié et NE DOIT PLUS ÊTRE UTILISÉ. En effet, une faille dans l'algorithme a été trouvée, permettant de diminuer considérablement le nombre d'opérations nécessaires à un inversement par rapport à une attaque force brute. De plus, et c'est le plus inquiétant, il a été montré qu'il était possible de créer volontairement des collisions avec un document donné. En effet, les hashs MD5 sont constitués de 32 caractères alphanumériques, soit 36³²= 6.33⁴⁹ combinaisons possibles. Ainsi, le nombre de hashs possibles est limité. Or, nous réalisons des hashs de chaîne de caractères (strings, fichiers…) de taille indéterminée et pour la plupart bien plus grandes que 32 caractères. Par exemple, nous pouvons constituer 2¹⁵⁵⁶ chaînes de 1000 caractères alphanumériques.
Nous avons donc une infinité de chaînes de caractères pouvant donner un hash précis et il est maintenant possible de déterminer instantanément les autres chaînes de caractères à partir d'une des chaînes et du hash.

Il est donc recommandé d'utiliser des algorithmes plus robustes, comme le SHA1 ou le SHA-256. Mais il faut bien garder en tête qu'un algorithme est reconnu comme fiable uniquement, car il n'a pas encore été craqué. Ainsi, le SHA1 est déjà sur la pente descendante, le nombre d'opérations nécessaires à l'inversion ayant été ramené de 2^80 à 2^63.

Maintenant que nous avons présenté le principe du hash et les principaux algorithmes, nous allons voir un exemple pratique de mise en place côté serveur et côté client.

print_r(hash_algos());

Array
(
    [0] => md4
    [1] => md5
    [2] => sha1
    [3] => sha256
    [4] => sha384
    [5] => sha512
    [6] => ripemd128
    [7] => ripemd160
    ...
);

III-A-2-a. Côté serveur▲

// A l'inscription
$pass = $_POST['pass'];
$login = $_POST['login'];
mysql_query("
    INSERT INTO membres (login, pass) 
    VALUES ('".mysql_real_escape_string($login)."', '".sha1($pass)."')");

// A la connexion
$pass = $_POST['pass'];
$login = $_POST['login'];
$result = mysql_query("
    SELECT 1 
    FROM membres 
    WHERE (login='".mysql_real_escape_string($login)."')
    AND (pass='".sha1($pass)."')");
if (mysql_num_rows($result) > 0)
{
    // on connecte
}

III-A-2-b. Côté client▲

<script type="text/javascript" src="sha1hash.js"></script>
<form method="post" action="" id="connexion-form" name="connexion-form" onsubmit="sha1hash(this.mdp, this.sha1mdp);">
    Pseudo : <input type="text" name="login" id="login" size="20" autocomplete="off">
    Mot de passe : <input type="password" name="mdp" size="20" />
    <input type="hidden" name="sha1mdp" value="" />
    <input value="Valider" id="Valider" type="submit" class="bouton">
</form>

// Javascript activé
if ( ! empty ($_POST['sha1mdp']) )
{
    $sha1mdp = $_POST['sha1mdp'];
}
// Javascript désactivé
elseif ( ! empty($_POST['mdp']) )
{
    $sha1mdp = sha1($_POST['mdp']);
}

Le but premier du GDS est de protéger le hash du mot de passe lors de son transfert et de son stockage. En effet, il est de plus en plus facile d'inverser un hash, nous utilisons donc le GDS afin de compliquer cette inversion.
Le grain de sel a deux intérêts très distincts suivant qu'il est utilisé côté client ou serveur.

Côté serveur

Cela signifie en pratique que l'on a hashé le mot de passe de l'utilisateur, préalablement concaténé avec le GDS, avant de l'enregistrer dans la base de données.
Ceci empêche le hacker, en cas de vol de la base de données, d'utiliser la force brute ou un dictionnaire pour inverser les hashs. En effet, comme le GDS est secret, le hacker ne pourra pas constituer de dictionnaire adapté. De plus, la force brute sera vraiment plus longue, car si le GDS est une chaîne de 32 caractères et le mot de passe une chaîne de 8 caractères alors il faudra tester 2.8¹² combinaisons sans GDS ou 1.8⁶² avec GDS.
Le fondement de cette protection est que le hacker ne connaît pas la valeur du GDS.

Côté client

Le GDS côté client suppose que le GDS ne soit pas secret. Il ne peut donc pas protéger des attaques par force brute. Par exemple, le mot de passe est « lol » et le GDS « azerty ». On appliquera le hash sur toutes les combinaisons possibles de « aaa » à « zzz » pour comparer chaque résultat au hash qu'on souhaite inverser. Avec un GDS connu, il suffira de tester les combinaisons de « azertyaaa » à « azertyzzz ». Cela ne complique en rien notre recherche.

Ce type de GDS protège contre les attaques par dictionnaire. En effet, depuis quelque temps, des dictionnaires de hash sont disponibles sur le NET, voire directement utilisables en ligne. On peut trouver des dictionnaires en ligne contenant plus de 500 millions de hashs référencés. Grâce à ces dictionnaires, il est possible de retrouver instantanément un mot de passe à partir du hash s'il est dans le dictionnaire.
Toute l'utilité de ce GDS est contenue dans ces mots « s'il est dans le dictionnaire », car si notre mot de passe « lol » y est très certainement, il y a peu de chances que « azertylol » y soit, et encore moins « skndgqzmsrgze6r4gb5q1fde5bhs3df4b3q4df3b4sdfblol ».

On voit dans ce tableau récapitulatif la faiblesse du « GDS côté client ». Si le hacker arrive à recueillir le GDS et le hash côté client, il pourra utiliser une technique de force brute traditionnelle, sans que nous lui ayons compliqué le travail. Le GDS côté serveur et côté client sont deux techniques complémentaires.

Il existe en réalité beaucoup plus de méthodes, mais elles impliquent toutes – à au moins l'une des étapes – le stockage ou la transmission du mot de passe en clair.
Nous noterons ici pour chaque technique l'efficacité de la protection correspondante :

• 0 = pas protégé
• 1 = peu protégé
• 2 = bien protégé
• 3 = très bien protégé

III-B-2-a. GDS global▲

III-B-2-b. GDS par utilisateur▲

III-B-2-c. GDS par session▲

protected_mdp = SHA1(SHA1(mdp+GDS1)+GDS2)

Nous allons ici approfondir la technique de protection par GDS propre à un utilisateur, car c'est la seule protégeant réellement d'une attaque par dictionnaire, étant donné qu'il faut constituer un dictionnaire par membre. Pour la réaliser, je vais utiliser un peu d'Ajax. Comme je l'ai dit plus haut, il est possible de réaliser deux formulaires au lieu du script Ajax, c'est le choix qu'a fait le projet SPIP (cf. rubrique lien à la fin de l'article). Le script Ajax utilisé s'appuie sur le tutoriel de Denis Cabasson disponible ici Tutoriel Ajax
Le principe consiste à lire le champ de login et à appeler une page distante à chaque changement observé. Ainsi, à chaque saisie d'un caractère dans le champ login, nous vérifierons si un utilisateur existe avec ce login et si oui, nous renverrons son GDS.

Un fichier JS pour réaliser ceci est disponible ici (getGDS.zip).
Il nous manque maintenant le formulaire et un fichier PHP renvoyant le GDS d'un utilisateur.

Côté client

Il est nécessaire dans la page d'insérer et d'initialiser les scripts de GDS et de hash, puis nous affichons le formulaire.

<script type="text/javascript">
    var _adresseRecherche = "gds.php"   // l'adresse à interroger pour trouver le GDS
</script>
<script type="text/javascript" src="sha1hash.js"></script>
<script type="text/javascript" src="getGDS.js"></script>
<script type="text/javascript">
    window.onload = function()
    {
        initGetGDS(
            document.getElementById('connexion-form'),
            document.getElementById('login'),
            document.getElementById('Valider'),
            document.getElementById('gds'),
            document.getElementById('info_gds')
            );
    };
</script>

La variable JS _adresseRecherche définit la page distante qu'il faudra appeler pour récupérer le GDS.
Pour initialiser le listener du champ login, nous appelons la fonction initGetGDS en lui passant comme paramètres les objets DOM

• du formulaire ;
• du champ login ;
• du bouton de submit ;
• du champ hidden dans lequel placer le GDS ;
• du div dans lequel on pourra indiquer si le GDS est bien réceptionné (optionnel).

<form method="post" action="" id="connexion-form" name="connexion-form" onsubmit="sha1hash(this.mdp, this.sha1mdp, this.gds);">
    Pseudo : <input type="text" name="login" id="login" size="20" autocomplete="off" />
    <div id="info_gds">Grain de sel</div><br />
    Mot de passe : <input type="password" name="mdp" size="20" /><br />
    <input type="hidden" name="sha1mdp" value="">
    <input type="hidden" name="gds" id="gds" value="">
    <input value="Valider" id="Valider" type="submit" class="bouton">
</form>

Le reste est identique au modèle présenté dans le chapitre consacré au hash, avec le GDS en plus. Le hash se fera ici selon le formulaire :
sha1mdp = sha1(GDS + mdp + GDS)

Côté serveur

Il s'agit d'un script très simple qui recherche dans la base de données ce login, sélectionne le GDS et en fait un écho. On pourrait établir un flux XML plus propre, mais pour l'exemple, un simple flux texte est suffisant.

if(isset($_GET['login']))
{
   $login = urldecode($_GET['login']);
}
else
{
   exit 0;
}
 
$gds = $db->get_var("SELECT me_gds FROM membres WHERE login='".mysql_real_escape_string($login)."'");
if ( !empty($gds) )
{
    echo $gds;
}

Le login est envoyé par GET, on le récupère, on applique un urldecode, car on a utilisé urlencode côté Javascript (dans le fichier getGDS.js).