downloads | documentation | faq | getting help | mailing lists | licenses | wiki | reporting bugs | php.net sites | conferences | my php.net

search for in the

PHP et HTML> <Utiliser PHP
[edit] Last updated: Fri, 26 Apr 2013

view this page in

Hashage de mots de passe sûr

Cette section explique les raisons d'utiliser des fonctions de hashage pour les mots de passe, ainsi que la façon de le faire efficacement.

Pourquoi devrais-je hasher les mots de passe envoyés par les utilisateurs de mon application ?

Le hashage de mot de passe est l'une des pratiques de sécurité les plus basiques qui doit être effectuée. Sans cela, chaque mot de passe stocké peut être volé si le support de stockage (typiquement une base de données) est compromis. Ce mot de passe peut alors être immédiatement utilisé pour accèder frauduleusement non seulement à votre application mais aussi sur d'autres applications si l'utilisateur utilise le même mot de passe ailleurs.

En appliquant un hashage sur le mot de passe avant de le stocker, vous rendez la tâche d'un attaquant très difficile pour connaitre le mot de passe original, et vous avez toujours la possibilité de comparer le mot de passe hashé à une chaîne reçue.

Il est important de noter que le hashage ne fait que protéger les mots de passe dans la base, pas leur éventuelle interception alors qu'ils sont envoyés à l'application par l'utilisateur, via du code malicieux injecté dans l'application, par exemple.

Pourquoi les fonctions traditionnelles de hashage comme md5() et sha1() sont-elles inappropriées aux mots de passe ?

Les algorithmes de hashage comme MD5, SHA1 et SHA256 sont destinés à être rapides et efficaces. Avec les équipements informatiques modernes, il est devenu facile d'attaquer par force brute la sortie de ces algorithmes pour retrouver la chaîne originale.

C'est la raison pour laquelle de nombreux experts en sécurité considèrent ces algorithmes comme faibles et les déconseillent fortement pour hasher un mot de passe utilisateur.

Alors, comment hasher mes mots de passe ?

Lorsqu'on hashe des mots de passe, les deux considérations les plus importantes sont le temps de traitement, et le grain de sel. Plus la puissance de traitement requise est élevée, plus il faudra du temps pour casser le mot de passe en analysant sa sortie.

Il existe deux fonctions fournies dans PHP pour hasher avec des algorithmes précis.

La première fonction de hashage est crypt(), elle supporte nativement plusieurs algorithmes. Lorsque vous utilisez cette fonction, vous êtes sûr que l'algorithme que vous choisissez est disponible, car PHP en contient des implémentations natives dans le cas où votre système ne les supporterait pas.

La deuxième fonction de hashage est hash(), elle supporte beaucoup plus d'algorithmes et de variantes que crypt(), mais elle n'en supporte pas certains que crypt() supporte. L'extension Hash est fournie avec PHP, mais elle peut être désactivée à la compilation, ainsi il n'est pas certain qu'elle soit présente, alors que crypt() l'est obligatoirement.

L'algorithme recommandé pour hasher des mots de passe est Blowfish, car il est nettement plus coûteux en calcul que MD5 ou SHA1 pour être cassé, tout en restant évolutif.

Qu'est ce que le grain de sel ?

Un grain de sel, en cryptographie, est appliqué durant le processus de hashage pour éliminer la possibilité d'attaques par dictionnaires (hashages enregistrés dans une grande liste et comparés).

En d'autres termes, un grain de sel est une petite donnée additionnelle qui renforce significativement la puissance du hashage pour le rendre beaucoup plus difficile à cracker. Il existe de nombreux services en ligne qui proposent de volumineux dictionnaires de mots de passe avec leur hash. L'utilisation d'un grain de sel rend ces dictionnaires inutiles.



PHP et HTML> <Utiliser PHP
[edit] Last updated: Fri, 26 Apr 2013
 
add a note add a note User Contributed Notes Hashage de mots de passe - [3 notes]
up
2
fluffy at beesbuzz dot biz
10 months ago
The security issue with simple hashing (md5 et al) isn't really the speed, so much as the fact that it's idempotent; two different people with the same password will have the same hash, and so if one person's hash is brute-forced, the other one will as well.  This facilitates rainbow attacks.  Simply slowing the hash down isn't a very useful tactic for improving security.  It doesn't matter how slow and cumbersome your hash algorithm is - as soon as someone has a weak password that's in a dictionary, EVERYONE with that weak password is vulnerable.

Also, hash algorithms such as md5 are for the purpose of generating a digest and checking if two things are probably the same as each other; they are not intended to be impossible to generate a collision for.  Even if an underlying password itself requires a lot of brute forcing to determine, that doesn't mean it will be impossible to find some other bit pattern that generates the same hash in a trivial amount of time.

As such: please, please, PLEASE only use salted hashes for password storage.  There is no reason to implement your own salted hash mechanism, either, as crypt() already does an excellent job of this.
up
4
sgbeal at googlemail dot com
7 months ago
sha1 in conjunction with one or more salt values need not be as insecure as the above makes it out to be. e.g. the Fossil SCM creates an sha1 password hash based on a user's clear-text password combined with the user's name and a shared secret known only to the specific source repository for which the user is set up.
up
-5
alice2287 at live dot com
1 year ago
For those wishing to increase the computational cost of brute-forcing their password hashes by iterating the hash command multiple times, but don't want to increase the risk of a hash collision, simply re-append the password to the hash each iteration.

<?php

$iterations
= 10;
$hash = crypt($password,$salt);
for (
$i = 0; $i < $iterations; ++$i)
{
   
$hash = crypt($hash . $password,$salt);
}

?>

This, of course, can be used with md5(), sha1(), etc. as well as crypt().

Some other recommendations:

- Use the highest number of iterations possible without introducing a significantly noticeable delay to authenticating users, or causing more CPU use than your host will allow.
- Use a unique salt for each user, ideally a random one.
- Use a salt of at least 24 bytes, especially if you're using a weaker algorithm like MD5 or SHA-1.

 
show source | credits | stats | sitemap | contact | advertising | mirror sites