Quelle est la longueur optimale du sel de mot de passe utilisateur? [fermé]


128

Tout sel aidera évidemment lors du salage et du hachage du mot de passe d'un utilisateur. Existe-t-il des meilleures pratiques pour la durée du sel? Je vais stocker le sel dans ma table utilisateur, je voudrais donc 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?


10
Je n'ai pas de recommandation sur la longueur du sel, mais les réponses qui apparaissent ici contiennent beaucoup de mauvaises informations. Votre sel doit absolument: - être aléatoire - être par secret (pas une seule valeur stockée dans l'image de votre programme ou le fichier de configuration). Le sel n'est pas un secret cryptographique, donc le stocker dans votre table n'est pas un problème. Le seul but d'un sel est de garantir que lorsque différentes instances du même élément sont hachées (ou chiffrées), vous obtenez un résultat différent.
Michael Burr

2
Pour ceux qui ne savent pas ce qu'est le sel: <a href=" en.wikipedia.org/wiki/Salt_(cryptography)"> Salt (cryptographie) </a> sur Wikipedia
David Koelle

1
Ou s'il existe un rapport optimal entre la longueur du sel et la longueur de la sortie de hachage? Le sel de 8 octets peut suffire pour HMAC-SHA-256, mais pas pour HMAC-SHA-512.
Crend King

1
Le sel cryptographiquement aléatoire de la même taille que la sortie de la fonction de hachage signifie qu'une attaque "essayez tous les sels possibles" (plus un dictionnaire de mots de passe) nécessite autant d'efforts qu'une attaque "essayez tous les résultats de hachage possibles" - qui est une force brute standard . Un salt plus court signifie que vous pouvez avoir un dictionnaire de sel et un dictionnaire de mots de passe en tant qu'attaque par force brute.
Richard Gadsden

-1 Il est vrai qu'il ne répond pas (même ne tente pas de) répondre à la question.
user359996

Réponses:


70

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 de l'inclusion 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 à ce qu'ils soient imprévisibles ou difficiles à deviner.

Les sels doivent seulement être assez longs pour que le sel de chaque utilisateur soit unique. Il est très peu probable que les sels 64 bits aléatoires se répètent même avec un milliard d'utilisateurs enregistrés, donc cela devrait être bien. Un sel unique répété est un problème de sécurité relativement mineur, il permet à un attaquant de rechercher deux comptes à la fois, mais dans l'ensemble, 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, ils accéléreront dans le pire des cas 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 sécurité de le faire.

Il y a un certain avantage à utiliser également un sel à l'échelle du site en plus du sel par utilisateur, cela empêchera les collisions possibles avec les hachages de mots de passe stockés sur d'autres sites, et empêchera l'utilisation de tables arc-en-ciel à usage général, bien que même 32 bits de le sel suffit à faire des tables arc-en-ciel une attaque impraticable.

Encore plus simple - et les développeurs oublient toujours cela - si vous avez des identifiants d'utilisateur ou des noms de connexion uniques, ceux-ci servent parfaitement bien 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.


16
Il y a un avantage à ce que les sels soient imprévisibles. Un sel prévisible pourrait être prédit et utilisé dans une attaque de table de hachage. Par exemple, si votre salt est juste le userID, alors une table de hachage alpha simple suffisamment longue comprendra non seulement tous les mots de passe, mais toutes les combinaisons nom d'utilisateur + mot de passe.
Richard Gadsden

6
Remarquez par rapport à votre dernier paragraphe, si vous utilisez un sel à l'échelle du site, cela devrait être exactement cela: à l'échelle du site. Pas à l'échelle de l'application, c'est-à-dire que chaque nouvelle instance que vous installez de votre application doit générer un nouveau salt à l'échelle du site. Par exemple, si Windows utilisait le même sel sur chaque base de données d'authentification Windows, alors il serait intéressant de créer une table arc-en-ciel pour ce sel, mais si chaque installation de Windows générait un nouveau sel, ce ne serait pas le cas.
Richard Gadsden

5
Le problème n'est pas vraiment que le sel doit être difficile à deviner. L'attaquant n'a pas besoin de deviner le sel: quiconque a accès au hachage a déjà le sel. Le problème est que si vos sels sont très courants (comme les noms d'utilisateur), ils peuvent être les mêmes que ceux d'autres sites, et à ce stade, l'attaquant a besoin d'un ensemble beaucoup plus petit de tables arc-en-ciel pour rendre les attaques réalisables. C'est pourquoi l'idée de sel par site est mentionnée, pour éviter ce genre de collision avec d'autres sites.
Nate CK

3
Note rapide: si vous utilisez des noms d'utilisateur comme sel, cela peut être un problème si les noms d'utilisateur changent. En pratique, (malgré ce qui est dit dans les documents de conception du client), j'ai constaté que les utilisateurs veulent souvent changer les noms d'utilisateur.
SilentSteel

5
@ NateC-K, L'idée de sel par site dont vous parlez s'appelle le poivre.
Pacerier

35

Les normes actuellement acceptées pour le hachage des mots de passe créent un nouveau sel de 16 caractères pour chaque mot de passe et stockent le sel avec le hachage du mot de passe.

Bien sûr, un soin cryptographique approprié pour créer du sel vraiment aléatoire doit être pris.


6
Le caractère est un peu mal défini. Vous devriez dire byte .
CodesInChaos

10
@CodesInChaos Je crois que vous voulez dire octet ;-)
user2864740

1
Salut! Il semble que l'article de wikipedia a changé - peut-être devriez-vous vous référer à en.wikipedia.org/wiki/PBKDF2 ou quelque chose?
Boris Treukhov


24

Edit: Ma réponse ci-dessous répond à la question telle que 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 que le sel ait exactement la même longueur 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 un sel de 256 bits.

Plus de 256 bits ne vous apporteront aucune amélioration de la sécurité, mathématiquement. Mais opter pour un sel plus court peut toujours se retrouver dans une situation où une table arc-en-ciel rattrape votre longueur de sel - en particulier avec des sels plus courts.


10
Ce n'est pas si grave; l'utilisateur remarquera à peine la différence entre un hachage de la milliseconde et un hachage d'une demi-seconde, et le hachage du mot de passe devrait en fait prendre plus de temps pour ralentir les attaques par force brute - bien que trois frappes typiques verrouillées pendant 15 minutes soient meilleures. Êtes-vous en train de «gaspiller» des cycles de processeur pour cela? Oui peut importe. De toute façon, le processeur passe plus de temps inactif que sur la plupart des sites Web, alors qu'importe? Si vous rencontrez des problèmes de performances, évoluez.
Randolpho

14
Les sels se défendent des tables arc-en-ciel. Un sel de 512 bits avec un hachage de 256 bits n'entraînera toujours que 256 bits d'entropie dans le mot de passe final.
Stephen Touset

8
Le hachage lent est une fonctionnalité, pas un bogue.
outis le

7
Si vous avez un hachage 3 bits, votre sel de 9999 bits ne hachera toujours que jusqu'à 3 bits d'entropie possibles. Une table arc-en-ciel n'aurait qu'à trouver trois sels pour chaque mot de passe qui se traduisent par une sortie différente, qui est un facteur multiplicatif constant et donc écartée du big-O.
Stephen Touset

2
.................................................. .................................... système particulier. Le but des sels est d'arrêter les attaques de pré-calcul afin que les hachages ne puissent pas être recherchés et immédiatement inversés en texte clair . Avec un sel de 9999 bits, votre mot de passe reste un secret , alors qu'avec un sel de 3 bits, votre mot de passe est maintenant connu du monde entier (et ils peuvent l'utiliser pour se connecter à vos autres comptes car de nombreuses personnes réutilisent souvent les mots de passe). Je trouve amusant que 5 personnes ici aient effectivement voté pour votre commentaire à cause du mot «entropie» qu'il contient.
Pacerier

7

Wikipédia :

Les méthodes SHA2-crypt et bcrypt - utilisées sous Linux, BSD Unix et Solaris - ont des sels de 128 bits. Ces valeurs de sel plus élevées rendent les attaques de précalcul pour presque n'importe quelle longueur de mot de passe irréalisables contre ces systèmes dans un avenir prévisible.

Un sel de 128 bits (16 octets) suffira. Vous pouvez le représenter sous la forme d'une séquence de 128 / 4 = 32chiffres hexadécimaux.


Il me semble qu'un exemple de ce qu'utilisent d'autres systèmes sécurisés est un excellent exemple de ce que sont les meilleures pratiques.
cjbarth

1
@ mklement0 Merci, j'ai mis à jour la réponse.
Andrii Nemchenko

2

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 allez utiliser SHA-512, utilisez 256 bits salt car la sécurité fournie par SHA-512 est de 256 bits.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.