Au travail, nous avons deux théories concurrentes pour les sels. Les produits que je travail sur utiliser quelque chose comme un nom d'utilisateur ou numéro de téléphone pour le sel de la table de hachage. Essentiellement quelque chose qui est différent pour chaque utilisateur mais il est facilement disponible pour nous. L'autre produit génère aléatoirement un sel pour chaque utilisateur et à chaque fois que l'utilisateur change le mot de passe. Le sel est ensuite crypté dans la base de données.
Ma question est de savoir si la seconde approche est-elle vraiment nécessaire? Je peux comprendre, d'un point de vue purement théorique qu'elle est plus sûre que la première approche, mais qu'à partir d'une pratique de point de vue. Maintenant pour authentifier un utilisateur, le sel doit être clair et appliqué pour les informations de connexion.
Après réflexion, je ne vois pas un réel gain de sécurité de cette approche. Modification du sel de compte à compte, fait qu'il est encore extrêmement difficile pour quelqu'un de tenter de la force brute de l'algorithme de hachage, même si l'attaquant a été conscient de la façon de rapidement déterminer ce qu'il était pour chaque compte. C'est en allant sur l'hypothèse que les mots de passe sont suffisamment fortes. (Évidemment de trouver la bonne valeur de hachage pour un jeu de mots de passe, où ils sont tous deux chiffres est beaucoup plus facile que de trouver le bon hash de mots de passe de 8 chiffres). Je suis incorrect dans ma logique, ou est-il quelque chose que je suis absent?
EDIT: Bon alors voici la raison pourquoi je pense que c'est vraiment discutable pour chiffrer le sel. (lemme de savoir si je suis sur la bonne voie).
Pour l'explication qui suit, nous allons supposer que les mots de passe sont toujours 8 caractères et le sel est 5 et tous les mots de passe composé de lettres minuscules (il fait juste les maths plus facile).
Ayant un autre sel pour chaque entrée signifie que je ne peux pas utiliser le même arc-en-ciel de la table (en fait, techniquement, je pourrais si j'en avais un de taille suffisante, mais ignorons le fait que pour le moment). C'est la véritable clé pour le sel de ce que je comprends, parce que pour le crack de chaque compte que j'ai de réinventer la roue, afin de parler de chacun d'eux. Maintenant, si je sais comment appliquer le bon de sel à un mot de passe pour générer le hachage, je le ferais, car un sel vraiment juste s'étend de la longueur et de la complexité du haché de la phrase. Donc, je serais d'une réduction du nombre de combinaisons possibles, j'ai besoin de générer de "savoir" j'ai le mot de passe + le sel de 13^26 à 8^26 parce que je sais ce que le sel est. Maintenant que c'est plus facile, mais encore très dur.
Donc sur le chiffrement du sel. Si je sais que le sel est crypté, je n'essayez pas de les déchiffrer (en supposant que je sais qu'il a un niveau suffisant de chiffrement) en premier. Je l'ignorer. Au lieu d'essayer de comprendre comment le décrypter, revenons à l'exemple précédent, je voudrais juste générer un plus grand arc-en-ciel de la table contenant toutes les clés pour la 13^26. Ne connaissant pas le sel serait certainement me ralentir, mais je ne pense pas que ce serait ajouter de la tâche monumentale d'essayer de casser le sel de chiffrement en premier. C'est pourquoi je ne pense pas que ça en vaut la peine. Pensées?
Voici un lien qui décrit combien de temps les mots de passe peut contenir jusqu'en vertu d'une attaque par force brute: http://www.lockdown.co.uk/?pg=combi
