Quelle est la longueur optimale pour le sel de mot de passe utilisateur?
N'importe quel sel aidera évidemment lors du salage et du hachage du mot de passe d'un utilisateur. Y a-t-il des meilleures pratiques pour combien de temps le sel devrait être? Je vais stocker le sel dans ma table utilisateur, donc je voudrais le meilleur compromis entre la taille du stockage et la sécurité. Un sel aléatoire de 10 caractères suffit-il? Ou ai-je besoin de quelque chose de plus?
La plupart de ces réponses sont un peu erronées et démontrent une confusion entre les sels et les clés cryptographiques. Le but d'inclure des sels est de modifier la fonction utilisée pour hacher le mot de passe de chaque utilisateur afin que chaque hachage de mot de passe stocké doive être attaqué individuellement. La seule exigence de sécurité est qu'ils sont uniques par utilisateur, il n'y a aucun avantage à les rendre imprévisibles ou difficiles à deviner.
Les sels doivent seulement être suffisamment longs pour que le sel de chaque utilisateur soit unique. Il est très peu probable que les sels aléatoires 64 bits se répètent même avec un milliard d'utilisateurs enregistrés, cela devrait donc être parfait. Un sel répété individuellement est un problème de sécurité relativement mineur, il permet à un attaquant de rechercher deux comptes à la fois, mais dans l'ensemble, cela n'accélérera pas beaucoup la recherche sur l'ensemble de la base de données. Même les sels 32 bits sont acceptables dans la plupart des cas, dans le pire des cas, ils accéléreront la recherche d'un attaquant d'environ 58%. Le coût de l'augmentation des sels au-delà de 64 bits n'est pas élevé, mais il n'y a aucune raison de le faire.
Il existe certains avantages à utiliser également un sel à l'échelle du site en plus du sel par utilisateur, cela empêchera les collisions possibles avec les hachages de mot de passe stockés sur d'autres sites, et empêchera l'utilisation de tables Rainbow à usage général, bien que même 32 bits de le sel suffit pour faire des tables Rainbow une attaque peu pratique.
Encore plus simple - et les développeurs l'oublient toujours - si vous avez des ID utilisateur ou des noms de connexion uniques, ceux-ci servent parfaitement comme sel. Si vous faites cela, vous devez ajouter un sel à l'échelle du site pour vous assurer de ne pas chevaucher les utilisateurs d'un autre système qui ont eu la même idée brillante.
Actuellement normes acceptées pour le hachage des mots de passe, créez un nouveau sel de 16 caractères pour chaque mot de passe et stockez le sel avec le hachage du mot de passe.
Bien sûr, un soin cryptographique approprié doit être pris pour créer du sel vraiment aléatoire.
Edit: ma réponse ci-dessous répond à la question posée, mais la "vraie" réponse est: utilisez simplement bcrypt , scrypt , ou Argon2 . Si vous posez des questions comme celle-ci, vous utilisez presque certainement des outils à un niveau trop bas.
Honnêtement, il n'y a aucune raison défendable de ne pas avoir la même longueur exacte que le mot de passe haché. Si vous utilisez SHA-256, vous disposez d'un hachage 256 bits. Il n'y a aucune raison de ne pas utiliser de sel 256 bits.
Plus de 256 bits ne vous apporteront aucune amélioration de la sécurité, mathématiquement. Mais aller avec un sel plus court peut toujours aboutir à une situation où une table Rainbow rattrape votre longueur de sel - en particulier avec des sels plus courts.
Les méthodes SHA2-crypt et bcrypt - utilisées sous Linux, BSD Unixes et Solaris - ont des sels de 128 bits. Ces valeurs de sel plus importantes rendent les attaques de pré-calcul pour presque n'importe quelle longueur de mot de passe impossibles contre ces systèmes dans un avenir prévisible.
Un sel de 128 bits (16 octets) sera suffisant. Vous pouvez le représenter comme une séquence de 128 / 4 = 32 chiffres hexadécimaux.
Une réponse pourrait être d'utiliser comme taille de sel la valeur que le hachage que vous allez utiliser fournit en termes de sécurité.
Par exemple. Si vous prévoyez d'utiliser SHA-512, utilisez du sel 256 bits car la sécurité fournie par SHA-512 est de 256 bits.