Comment hacher en toute sécurité des mots de passe?
Si je hache des mots de passe avant de les stocker dans ma base de données, est-ce suffisant pour empêcher qu'ils ne soient récupérés par quelqu'un?
Je dois souligner que cela ne concerne que la récupération directement à partir de la base de données, et pas tout autre type d'attaque, comme la brutalisation de la page de connexion de l'application, l'enregistreur de frappe sur le client et bien sûr crypto-analyse en caoutchouc (ou de nos jours nous devrions l'appeler " Chocolate Cryptanalysis ").
Bien entendu, toute forme de hachage n'empêchera pas ces attaques.
bcrypt serait plus lent sur les GPU, ce qui ralentit le forçage brutal. Cependant, avec un matériel informatique en constante évolution, nous ne devons pas seulement compter sur la difficulté de mettre en œuvre un algorithme de hachage particulier sur un matériel particulier.
Au contraire, vous pouvez augmenter arbitrairement le coût de renforcement brutal d'un hachage en utilisant le "facteur travail/coût variable" (parfois aussi appelé "tours") pris en charge par certaines fonctions de hachage. Parmi eux, bcrypt et SHA-512.
La fonction crypt() de Glibc permet de spécifier des tours pour certains algorithmes de hachage. Par exemple, un facteur de coût de 100000 pour SHA-512 rend la génération (et donc le forçage brutal) du hachage environ 4 fois plus lente que le facteur de coût 08 pour bcrypt. Cela peut être confirmé en utilisant un programme de résolution de hachage comme hashcat.
Si vous supposez qu'à un moment donné votre hachage de mot de passe et vos sels seront volés et que les attaquants utiliseront le matériel ASIC pour les forcer brutalement, vous augmentez simplement le facteur de travail pour le rendre encore trop coûteux pour eux, sans surcharger le processeur de votre serveur avec une authentification utilisateur régulière.
L'importance de mots de passe longs et aléatoires s'applique néanmoins.
Je viens d'écrire un article de blog sur les détails.