I feel like I should comment some of the clams being posted as replies here.
For starters, speed IS an issue with MD5 in particular and also SHA1. I've written my own MD5 bruteforce application just for the fun of it, and using only my CPU I can easily check a hash against about 200mill. hash per second. The main reason for this speed is that you for most attempts can bypass 19 out of 64 steps in the algorithm. For longer input (> 16 characters) it won't apply, but I'm sure there's some ways around it.
If you search online you'll see people claiming to be able to check against billions of hashes per second using GPUs. I wouldn't be surprised if it's possible to reach 100 billion per second on a single computer alone these days, and it's only going to get worse. It would require a watt monster with 4 dual high-end GPUs or something, but still possible.
Here's why 100 billion per second is an issue:
Assume most passwords contain a selection of 96 characters. A password with 8 characters would then have 96^8 = 7,21389578984e 15 combinations.
With 100 billion per second it would then take 7,21389578984e 15 / 3600 = ~20 hours to figure out what it actually says. Keep in mind that you'll need to add the numbers for 1-7 characters as well. 20 hours is not a lot if you want to target a single user.
So on essence:
There's a reason why newer hash algorithms are specifically designed not to be easily implemented on GPUs.
Oh, and I can see there's someone mentioning MD5 and rainbow tables. If you read the numbers here, I hope you realize how incredibly stupid and useless rainbow tables have become in terms of MD5. Unless the input to MD5 is really huge, you're just not going to be able to compete with GPUs here. By the time a storage media is able to produce far beyond 3TB/s, the CPUs and GPUs will have reached much higher speeds.
As for SHA1, my belief is that it's about a third slower than MD5. I can't verify this myself, but it seems to be the case judging the numbers presented for MD5 and SHA1. The issue with speeds is basically very much the same here as well.
The moral here:
Please do as told. Don't every use MD5 and SHA1 for hasing passwords ever again. We all know passwords aren't going to be that long for most people, and that's a major disadvantage. Adding long salts will help for sure, but unless you want to add some hundred bytes of salt, there's going to be fast bruteforce applications out there ready to reverse engineer your passwords or your users' passwords.Hachage des mots de passe de manière sûre et sécurisée
Cette section explique les raisons d'utiliser des fonctions de hachage pour les mots de passe, ainsi que la façon de le faire efficacement.
- Pourquoi devrais-je hacher les mots de passe envoyés par les utilisateurs de mon application ?
- Pourquoi les fonctions traditionnelles de hachage comme md5 et sha1 sont-elles inappropriées aux mots de passe ?
- Comment les mots de passe doivent-ils être hachés, si les fonctions de hachage courantes ne sont pas adaptées ?
- Qu'est ce que le grain de sel ?
- Comment sont stocker les salts ?
-
Pourquoi devrais-je hacher les mots de passe envoyés par les utilisateurs de mon application ?
-
Le hachage des mots de passe est l'une des considérations de sécurité les plus élémentaires qui doivent être prises lors de la conception de toute application ou service qui accepte des mots de passe des utilisateurs. Sans hachage, tout mot de passe stocké peut être volé si le stockage de données est compromis, et être immédiatement utilisé pour compromettre non seulement l'application ou le service, mais aussi les comptes des utilisateurs sur d'autres services, s'ils n'utilisent pas des mots de pass uniques.
En appliquant un hachage sur le mot de passe, 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 hachage 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 hachage comme md5() et sha1() sont-elles inappropriées aux mots de passe ?
-
Les algorithmes de hachage 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 hacher un mot de passe utilisateur.
-
Comment les mots de passe doivent-ils être hachés, si les fonctions de hachage courantes ne sont pas adaptées ?
-
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.
PHP fournit une API native de hachage de mot de passe qui gère à la fois le hachage et la vérification de mots de passe, le tout, de manière totalement sécurisée.
L'algorithme suggéré à utiliser pour le hachage de mots de passe est Blowfish, qui est aussi l'algorithme par défaut de l'API de hachage de mots de passe, sachant qu'il est significativement plus gourmand en calcul que MD5 ou SHA1, mais plus évolutif.
La fonction crypt() est également disponible pour le hachage des mots de passe, mais elle n'est recommandée que pour l'interopérabilité avec d'autres systèmes. Il est plutôt fortement conseillé d'utiliser l' API native de hachage des mots de passe dès que possible.
-
Qu'est ce que le grain de sel ?
-
Un grain de sel, ou "salt", en cryptographie, est appliqué durant le processus de hachage pour éliminer la possibilité d'attaques par dictionnaires (hachages enregistrés dans une grande liste et comparés).
En termes plus simples, un sel est une donnée supplémentaire qui rend les hachages beaucoup plus difficiles à casser. Il existe plusieurs services en ligne qui fournissent des listes étendues de hachages pré-calculés, ainsi que l'entrée d'origine de ces hachages. L'utilisation d'un sel rend improbable ou impossible de trouver le hachage correspondant dans l'une de ces listes.
password_hash() va créer un salt aléatoire si vous n'en fournissez pas, et c'est généralement la façon la plus sécurisée et la plus simple.
-
Comment sont stocker les salts ?
-
Lors de l'utilisation de la fonction password_hash() ou de la fonction crypt(), la valeur retournée inclue le salt comme parti du hash généré. Cette valeur devrait être stockée telle quelle dans la base de données, sachant qu'elle inclue les informations sur la fonction de hachage utilisée et peut donc être fournie directement à la fonction password_verify() ou la fonction crypt() lors de la vérification des mots de passe.
Avertissementpassword_verify() doit toujours être utilisé au lieu de rehacher et comparer le résultat à un hachage stocké afin d'éviter les attaques par chronométrage.
Le diagramme suivant montre le format d'une valeur retournée de la fonction crypt() ou password_hash(). Comme on peut le voir, tout est présent, comme toutes les informations sur l'algorithme et le salt nécessaires pour une future vérification de mots de passe.
＋add a note
User Contributed Notes 3 notes
alf dot henrik at ascdevel dot com ¶
10 years ago
swardx at gmail dot com ¶
8 years ago
A great read..
https://nakedsecurity.sophos.com/2013/11/20/serious-security-how-to-store-your-users-passwords-safely/
Serious Security: How to store your users’ passwords safely
In summary, here is our minimum recommendation for safe storage of your users’ passwords:
Use a strong random number generator to create a salt of 16 bytes or longer.
Feed the salt and the password into the PBKDF2 algorithm.
Use HMAC-SHA-256 as the core hash inside PBKDF2.
Perform 20,000 iterations or more. (June 2016.)
Take 32 bytes (256 bits) of output from PBKDF2 as the final password hash.
Store the iteration count, the salt and the final hash in your password database.
Increase your iteration count regularly to keep up with faster cracking tools.
Whatever you do, don’t try to knit your own password storage algorithm.
tamas at microwizard dot com ¶
3 years ago
While I am reading the comments some old math lessons came into my mind and started thinking. Using constants in a mathematical algorythms do not change the complexity of the algorythm itself.
The reason of salting is to avoid using rainbow tables (sorry guys this is the only reason) because it speeds up (shortcuts) the "actual" processing power.
(((Longer stored hashes AND longer password increases complexity of cracking NOT adding salt ALONE.)))
PHP salting functions returns all the needed information for checking passwords, therfore this information should be treated as constant from farther point of view. It is also a target for rainbow tables (sure: for much-much larger ones).
What is the solution?
The solution is to store password hash and salt on different places.
The implementation is yours. Every two different places will be good enough.
Yes, it will make problems for hackers. He/she needs to understand your system. No speed up for password cracking will work for him/her without reimplementing your whole system.
This is my two cent.