Stocker les mots de passe en clair expose tous les comptes dès qu'une base de données fuite. C'est pourquoi les mots de passe sont convertis en hachage avant d'être stockés, et l'on compare à la connexion le hachage de la valeur saisie. Comme le texte original n'est pas conservé, on ne peut pas connaître immédiatement le mot de passe même en cas de fuite.
Mais un simple hachage SHA-256 ne suffit pas. Comme un même mot de passe produit toujours le même hachage, un attaquant peut effectuer des comparaisons massives à l'aide de tables arc-en-ciel (rainbow tables) précalculant les hachages des mots de passe courants. Pour l'empêcher, il faut ajouter à chaque compte une valeur aléatoire, le sel (salt), avant de hacher.
La vitesse pose aussi problème. SHA-256 est très rapide, permettant à un attaquant de tester des milliards de candidats par seconde. C'est pourquoi on emploie pour les mots de passe des hachages dédiés volontairement lents comme bcrypt, scrypt ou Argon2. En ajustant le nombre d'itérations et le coût mémoire, ils ralentissent considérablement les attaques par force brute.
En résumé, les trois principes du stockage des mots de passe sont : sel + hachage dédié lent + paramètres de coût suffisants. SHA-256/512 conviennent à l'intégrité des fichiers et à la signature, mais pour le stockage des mots de passe, utilisez un algorithme dédié comme Argon2.