Saler votre mot de passe: les meilleures pratiques?

J'ai toujours été curieux ... Qu'est-ce qui est mieux quand on salue un mot de passe pour le hachage: préfixe ou suffixe? Pourquoi? Ou est-ce important, tant que vous salez?

Pour expliquer: Nous savons tous (espérons-le) maintenant que nous devons saler un mot de passe avant de le hacher pour le stocker dans la base de données [ Edit: Vous pouvez donc éviter des choses comme ce qui est arrivé récemment à Jeff Atwood ]. En règle générale, cela se fait en concaténant le sel avec le mot de passe avant de le transmettre à l'algorithme de hachage. Mais les exemples varient ... Certains exemples ajoutent le sel avant le mot de passe. Certains exemples ajoutent le sel après le mot de passe. J'en ai même vu qui essaient de mettre le sel au milieu.

Alors, quelle est la meilleure méthode et pourquoi? Existe-t-il une méthode qui diminue le risque de collision de hachage? Mon googling n'a pas abouti à une analyse décente sur le sujet.

Edit: Excellentes réponses les gens! Je suis désolé de n'avoir pu choisir qu'une seule réponse. :)

Le préfixe ou le suffixe n'est pas pertinent, il ne s'agit que d'ajouter une certaine entropie et une longueur au mot de passe.

Vous devriez considérer ces trois choses:

1. Le sel doit être différent pour chaque mot de passe que vous stockez. (C'est un malentendu assez courant.)
2. Utilisez un générateur de nombres aléatoires sécurisé par cryptographie.
3. Choisissez un sel assez long. Pensez au problème de l'anniversaire.

Il y a une excellente réponse de Dave Sherohman à une autre question, pourquoi vous devriez utiliser des sels générés aléatoirement au lieu du nom d'un utilisateur (ou d'autres données personnelles). Si vous suivez ces suggestions, peu importe où vous mettez votre sel.

Je pense que tout est sémantique. Le mettre avant ou après n'a pas d'importance, sauf contre un modèle de menace très spécifique.

Le fait qu'il soit là est censé vaincre les tables arc-en-ciel.

Le modèle de menace auquel j'ai fait allusion serait le scénario dans lequel l'adversaire peut avoir des tables arc-en-ciel de sels communs ajoutés / ajoutés au mot de passe. (Dites la NSA) Vous devinez qu'ils l'ont soit ajouté ou ajouté, mais pas les deux. C'est idiot, et c'est une mauvaise supposition.

Il vaudrait mieux supposer qu'ils ont la capacité de stocker ces tables arc-en-ciel, mais pas, disons, des tables avec des sels étranges intercalés au milieu du mot de passe. Dans ce cas précis, je supposerais que les intercalaires seraient les meilleurs.

Comme je l'ai dit. C'est de la sémantique. Choisissez un sel différent par mot de passe, un sel long et ajoutez-y des caractères impairs comme des symboles et des codes ASCII: © ¤¡

La vraie réponse, que personne ne semble avoir abordée, est que les deux sont faux . Si vous implémentez votre propre crypto, quelle que soit l'insignifiante partie que vous pensez faire, vous allez faire des erreurs.

HMAC est une meilleure approche, mais même dans ce cas, si vous utilisez quelque chose comme SHA-1, vous avez déjà choisi un algorithme qui ne convient pas au hachage de mot de passe en raison de sa conception pour la vitesse. Utilisez quelque chose comme bcrypt ou éventuellement scrypt et retirez complètement le problème de vos mains.

Oh, et ne pensez même pas à comparer les hachages résultants pour l'égalité avec votre langage de programmation ou vos utilitaires de comparaison de chaînes de base de données. Ceux-ci comparent caractère par caractère et court-circuitent comme falsesi un caractère différait. Les attaquants peuvent désormais utiliser des méthodes statistiques pour essayer de déterminer ce qu'est le hachage, un caractère à la fois.

Cela ne devrait faire aucune différence. Le hasch ne sera plus facilement devinable où que vous mettiez le sel. Les collisions de hachage sont à la fois rares et imprévisibles, car elles sont intentionnellement non linéaires. Si cela faisait une différence pour la sécurité, cela suggérerait un problème de hachage, pas de salage.

Si vous utilisez un hachage cryptographiquement sécurisé, peu importe que vous préfixiez ou postfixer; un point de hachage est qu'un simple changement de bit dans les données source (peu importe où) devrait produire un hachage différent.

Ce qui est important, cependant, est d'utiliser des sels longs, de les générer avec un PRNG cryptographique approprié et d'avoir des sels par utilisateur. Le stockage des sels par utilisateur dans votre base de données n'est pas un problème de sécurité, mais l'utilisation d'un hachage à l'échelle du site l' est .

Tout d'abord, le terme «table arc-en-ciel» est systématiquement mal utilisé. Une table "arc-en-ciel" est juste un type particulier de table de recherche, une table qui permet un type particulier de compression de données sur les clés. En échangeant le calcul contre de l'espace, une table de recherche qui prendrait 1000 To peut être compressée mille fois afin de pouvoir être stockée sur un lecteur plus petit.

Vous devriez vous inquiéter du hachage des tables de recherche de mots de passe, arc-en-ciel ou autre.

@ onebyone.livejournal.com:

L'attaquant a des 'rainbow tables' constituées non pas des hachages de mots du dictionnaire, mais de l'état du calcul de hachage juste avant de finaliser le calcul de hachage.

Il pourrait alors être moins cher de forcer brutalement une entrée de fichier de mot de passe avec le sel de suffixe que le préfixe salt: pour chaque mot du dictionnaire à son tour, vous chargez l'état, ajoutez les octets de sel dans le hachage, puis finalisez-le. Avec le sel préfixé, il n'y aurait rien de commun entre les calculs pour chaque mot du dictionnaire.

Pour une simple fonction de hachage qui balaye linéairement la chaîne d'entrée, comme un simple générateur congruentiel linéaire, il s'agit d'une attaque pratique. Mais une fonction de hachage cryptographiquement sécurisée est délibérément conçue pour avoir plusieurs tours, chacun utilisant tous les bits de la chaîne d'entrée, de sorte que le calcul de l'état interne juste avant l'ajout du sel n'est pas significatif après le premier tour. Par exemple, SHA-1 a 80 tours.

De plus, les algorithmes de hachage de mot de passe comme PBKDF composent leur fonction de hachage plusieurs fois (il est recommandé d'itérer PBKDF-2 au moins 1000 fois, chaque itération appliquant SHA-1 deux fois) rendant cette attaque doublement impraticable.

BCrypt hash si la plate-forme a un fournisseur. J'aime le fait que vous ne vous inquiétez pas de la création des sels et que vous pouvez les rendre encore plus forts si vous le souhaitez.

L'insertion du sel d'un nombre arbitraire de caractères dans le mot de passe est le cas le moins attendu, et donc le plus «sécurisé» socialement, mais ce n'est vraiment pas très important dans le cas général tant que vous utilisez un mot de passe long et unique cordes pour sels.