Tous sel sera évidemment utile pour saler et hacher le mot de passe d'un utilisateur. Existe-t-il des bonnes pratiques concernant la durée du sel ? Je vais stocker le sel dans ma table d'utilisateurs, donc je voudrais le meilleur compromis entre la taille de stockage et la sécurité. Un sel aléatoire de 10 caractères est-il suffisant ? Ou ai-je besoin de quelque chose de plus long ?
Réponses
Trop de publicités?
SecurityJoe
Points
431
La plupart de ces réponses sont quelque peu erronées et démontrent une confusion entre les sels et les clés cryptographiques. L'inclusion de sels a pour but de modifier la fonction utilisée pour hacher le mot de passe de chaque utilisateur, de sorte que chaque hachage de mot de passe stocké devra être attaqué individuellement. La seule exigence de sécurité est qu'ils soient uniques par utilisateur, il n'y a aucun avantage à ce qu'ils soient imprévisibles ou difficiles à deviner.
Les sels doivent être suffisamment longs pour que le sel de chaque utilisateur soit unique. Il est très peu probable que des sels aléatoires de 64 bits se répètent, même avec un milliard d'utilisateurs enregistrés, et cela devrait donc suffire. Un sel répété une seule fois est un problème de sécurité relativement mineur, il permet à un attaquant de rechercher deux comptes à la fois, mais dans l'ensemble, il n'accélère pas beaucoup la recherche sur l'ensemble de la base de données. Même les sels de 32 bits sont acceptables dans la plupart des cas. Dans le pire des cas, ils accélèrent la recherche d'un pirate 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 pour des raisons de sécurité.
L'utilisation d'un sel à l'échelle du site en plus du sel par utilisateur présente certains avantages : elle permet d'éviter les collisions éventuelles avec les hachages de mots de passe stockés sur d'autres sites et empêche l'utilisation de tables arc-en-ciel à usage général, bien que même 32 bits de sel suffisent à faire des tables arc-en-ciel une attaque irréalisable.
Plus simplement encore - et les développeurs l'oublient toujours - si vous avez des identifiants d'utilisateur ou des noms de connexion uniques, ceux-ci peuvent parfaitement servir de sel. Dans ce cas, vous devez ajouter un sel pour l'ensemble du site afin d'éviter tout chevauchement avec les utilisateurs d'un autre système qui ont eu la même idée géniale.
David Schmitt
Points
29384
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 entendu, il convient de prendre les précautions cryptographiques qui s'imposent pour créer des sels vraiment aléatoires.
Stephen Touset
Points
1049
Edit : Ma réponse ci-dessous répond à la question telle qu'elle a été posée, mais la "vraie" réponse est : il suffit d'utiliser bcrypt , scrypt o Argon2 . Si vous posez ce genre de questions, vous utilisez certainement des outils d'un niveau trop bas.
Honnêtement, il n'y a aucune raison valable de ne pas faire en sorte que le sel ait exactement la même longueur que le mot de passe haché. Si vous utilisez SHA-256, vous avez un hachage de 256 bits. Il n'y a aucune raison de ne pas utiliser un sel de 256 bits.
Plus de 256 bits ne vous apportera aucune amélioration de la sécurité, mathématiquement. Mais si vous optez pour un sel plus court, vous risquez toujours de vous retrouver dans une situation où une table arc-en-ciel rattrape la longueur de votre sel - surtout avec des sels plus courts.
andreyne
Points
3652
Les algorithmes SHA2-crypt et bcr Solaris - ont des sels de 128 bits. Ces valeurs de sel plus importantes permettent de les attaques par précalcul pour presque toutes les longueurs de mot de passe. contre ces systèmes dans un avenir prévisible.
Un sel de 128 bits (16 octets) suffit. Vous pouvez le représenter comme une séquence de 128 / 4 = 32 chiffres hexadécimaux.
boos
Points
226
