Saler votre mot de passe: meilleures pratiques?

Question

J'ai toujours été curieux... ce Qui est mieux quand le salage un mot de passe pour le hachage: préfixe ou un suffixe? Pourquoi? Ou est-il question, aussi longtemps que vous le sel?

Pour expliquer: Nous avons tous (je l'espère), le savoir maintenant que nous devrions sel un mot de passe avant de nous hachage pour le stockage dans la base de données [Edit: de Sorte que vous pouvez éviter des choses comme ce qui est arrivé à Jeff Atwood récemment]. Typiquement, cela se fait en ajoutant le sel avec le mot de passe avant de le transmettre par le biais de l'algorithme de hachage. Mais les exemples varient... Quelques exemples ajouter le sel avant de le mot de passe. Quelques exemples d'ajouter le sel après le mot de passe. J'ai même vu certains qui tentent de mettre le sel dans le milieu.

Alors, quelle est la meilleure méthode, et pourquoi? Est-il une méthode qui diminue la probabilité d'une collision de hachage? Mes recherches sur Google n'a pas mis en place un décent d'analyse sur le sujet.

Edit: d'excellentes réponses! Je suis désolé, je ne pouvais choisir qu'une seule réponse. :)

Answer 1

Le préfixe ou le suffixe n'est pas pertinent, c'est seulement sur l'ajout de certains d'entropie et de la longueur du mot de passe.

Vous devez tenir compte de ces trois choses:

1. Le sel doit être différent pour chaque mot de passe que vous stockez. (C'est un malentendu commun.)
2. L'utilisation d'un point de vue cryptographique sécurisé générateur de nombre aléatoire.
3. Choisissez une assez longue de sel. Réfléchir sur le problème d'anniversaire.

Il y a une excellente réponse par Dave Sherohman à la question de savoir pourquoi vous devriez l'utiliser généré de façon aléatoire des sels au lieu d'un nom d'utilisateur (ou d'autres données personnelles). Si vous suivez ces suggestions, il vraiment n'importe pas où vous avez mis votre sel.

Answer 2

Je crois que c'est de la sémantique. Le mettre avant ou après n'a pas d'importance, sauf contre une menace spécifique du modèle.

Le fait qu'il y est censé vaincre rainbow tables.

Le modèle de menace auquel j'ai fait allusion serait le scénario où l'adversaire peut avoir des tables arc-en-ciel de la commune de sels ajoutés/ajouté le mot de passe. (Disons que la NSA), Vous êtes deviner qu'ils ont soit-il ajouté après ou avant, mais pas les deux. C'est idiot, et c'est un pauvre deviner.

Il ferais mieux de croire qu'ils ont la capacité de stocker ces tables arc-en-ciel, mais pas, disons, des tables avec des étranges sels intercalés au milieu du mot de passe. Dans cette étroite cas, je conjecture que entrecoupées serait le mieux.

Comme je l'ai dit. C'est de la sémantique. Choisir un autre sel par mot de passe, un long sel, et comprennent impair de caractères comme des symboles et des codes ASCII: ©¤¡

Answer 3

La vraie réponse, personne ne semble avoir touché, c'est que les deux ont tort. Si vous êtes à la mise en œuvre de votre propre crypto, peu importe comment trivial une partie de vous que vous êtes en train de faire, vous allez faire des erreurs.

HMAC est une meilleure approche, mais même alors, si vous êtes en utilisant quelque chose comme SHA-1, vous avez déjà choisi un algorithme qui n'est pas compatible pour le hachage de mot de passe en raison de son design pour la vitesse. Utilisez quelque chose comme bcrypt ou éventuellement scrypt et de prendre le problème de vos mains entièrement.

Oh, et ne pensez même pas à comparer les hachages de l'égalité avec les avec votre langage de programmation ou de base de données de comparaison de chaîne utilitaires. Ceux de comparer caractère par caractère et de court-circuit false si l'un des personnages diffère. Alors maintenant, les attaquants peuvent utiliser des méthodes statistiques pour essayer de travailler sur ce que le hachage est, un caractère à la fois.

Answer 4

Cela ne devrait pas faire de différence. Le hash ne sera plus facilement devinable où que vous mettiez le sel. Les collisions par 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 avec le hachage, pas le salage.

Answer 5

Si vous utilisez un hachage sécurisé sur le plan de la cryptographie, cela ne devrait pas vous déranger, que ce soit avant ou après. un point de hachage est qu'un seul changement de bit dans les données sources (peu importe où) devrait produire un hachage différent.

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