Comment les mots de passe doivent-ils être stockés, et que signaleriez-vous en revue si vous voyiez une implémentation existante ?

Hachez avec une fonction lente et gourmande en mémoire : Argon2id est la recommandation actuelle, bcrypt et scrypt restent acceptables. Chaque mot de passe reçoit un sel unique, que ces algorithmes génèrent et stockent dans la sortie, et les paramètres doivent être réglés pour que le hachage prenne une fraction notable de seconde sur votre matériel. N'utilisez jamais un hachage rapide simple comme SHA-256 ou MD5, ne chiffrez jamais les mots de passe de façon réversible, et rehachez à la connexion quand vous augmentez les paramètres.

Argon2id est ce vers quoi je vais, avec bcrypt en repli si la bibliothèque de la plateforme est mieux supportée. L'idée, c'est qu'il est délibérément lent et gourmand en mémoire, pour qu'un attaquant qui a le dump ne puisse pas tester des milliards de candidats par seconde sur une carte graphique. Chaque mot de passe reçoit son propre sel aléatoire, que ces algorithmes intègrent dans la sortie encodée, donc des mots de passe identiques produisent des empreintes différentes et les tables précalculées ne servent à rien. Je règle les paramètres sur du vrai matériel, en visant quelques centaines de millisecondes par hachage, et je les stocke avec l'empreinte pour pouvoir les augmenter plus tard et rehacher de façon transparente à la prochaine connexion réussie. En revue, ce que je signale, c'est un SHA-256 ou un MD5 nu, tout ce qui est réversible, un sel global unique, et avec bcrypt en particulier le fait qu'il ignore silencieusement l'entrée au-delà de 72 octets, ce qui affaiblit discrètement les longues phrases de passe. Au-delà du hachage, je veux une limitation de débit sur la connexion, une vérification contre les mots de passe connus comme compromis, et un flux de réinitialisation avec des jetons à usage unique et à expiration.