Si je hache les mots de passe avant de les stocker dans ma base de données, est-ce suffisant pour empêcher qu'ils soient récupérés par quiconque ?
Je précise que cela ne concerne que la récupération directement à partir de la base de données, et non tout autre type d'attaque, comme le bruteforcing de la page de connexion de l'application, le keylogger sur le client, et bien sûr la rubberhose cryptanalysis (ou de nos jours nous devrions l'appeler " ;[Chocolate Cryptanalysis][1]" ;).
Bien sûr, toute forme de hachage n'empêchera pas ces attaques.
[1] : http://www.theregister.co.uk/2007/04/17/chocolate_password_survey/
Les mots de passe stockés dans une base de données sous forme de valeurs hachées peuvent être récupérés soit par un calcul par force brute des hachages, soit par l'utilisation de tables arc-en-ciel (qui sont spécifiques à l'algorithme utilisé).
Une table arc-en-ciel est créée sous la forme d'une série de valeurs précalculées pour un fichier de dictionnaire ou, plus couramment, pour chaque combinaison d'un jeu de caractères donné [a-z, A-Z, 0-9], qui est un exemple courant.
Essentiellement, elles peuvent accélérer le craquage d'un mot de passe en permettant la recherche de la valeur de hachage dans la table plutôt que de demander à l'attaquant de créer le hachage pour chaque mot de passe. Les tables arc-en-ciel pour les algorithmes de mot de passe les plus courants (par exemple, NTLM, MD5, etc.) peuvent être trouvées en ligne, ce qui permet d'accéder assez facilement à de grandes quantités d'entre elles.
Il existe un certain nombre de moyens d'améliorer la sécurité des hachages stockés dans la base de données.
La première est d'utiliser une valeur de sel par utilisateur, cette valeur est stockée dans la base de données avec le mot de passe haché. Elle n'est pas destinée à être secrète mais est utilisée pour ralentir le processus de force brute et rendre les tables arc-en-ciel peu pratiques à utiliser.
Un autre ajout que j'ai vu est l'ajout de ce que l'on appelle une valeur poivrée. Il s'agissait d'une autre chaîne aléatoire, mais identique pour tous les utilisateurs et stockée avec le code d'application plutôt que dans la base de données. La théorie ici est que dans certaines circonstances, la base de données peut être compromise mais pas le code d'application, et dans ces cas, cela pourrait améliorer la sécurité. Cependant, cela pose des problèmes si plusieurs applications utilisent la même base de données de mots de passe.
Un troisième moyen d'améliorer la sécurité des mots de passe est d'utiliser une fonction de mot de passe lent, ce qui n'aura pas un impact énorme sur les utilisateurs individuels, mais ralentira massivement un attaquant dans le craquage des mots de passe récupérés dans la base de données. De plus amples informations sur cette approche sont disponibles [ici][1].
Le mot de passe doit toujours être haché, mais cela ne signifie pas qu'il n'y a aucune possibilité d'attaque par force brute. Des mesures supplémentaires doivent être appliquées concernant le stockage et la gestion des mots de passe des utilisateurs. Je recommande vivement cet article de Solar Designer sur ce sujet : http://php-security.org/2010/05/26/mops-submission-10-how-to-manage-a-php-applications-users-and-passwords/index.html.
Selon l'algorithme que vous utilisez, la réponse est probablement non.
Tout d'abord, vous devez les saler, ce qui signifie essentiellement ajouter ou précéder un texte au mot de passe.
Ensuite, vous devez utiliser un algorithme fort (md5 ne suffit pas).