Comment peut-bcrypt ont intégré des sels ?

Question

Coda Hale de l'article "Comment Stocker en toute sécurité d'un Mot de passe" affirme que:

bcrypt a sels intégré pour éviter que l'arc-en-ciel de la table des attaques.

Il cite ce document, qui dit que dans OpenBSD de la mise en œuvre de l' bcrypt:

OpenBSD génère 128 bits bcrypt de sel à partir d'un arcfour (arc4random(3)) flux clé, ensemencés avec des données aléatoires du noyau collecte à partir d'un périphérique de timing.

Je ne comprends pas comment cela peut fonctionner. Dans ma conception de sel:

• Il doit être différent pour chaque mot de passe enregistré, ainsi qu'un arc-en-ciel de la table devrait être généré pour chaque
• Il doit être stocké quelque part alors que c'est répétitif: lorsqu'un utilisateur essaie de se connecter, nous prenons leur tentative de mot de passe, répétez la même sel et le hachage de procédure nous avons fait lorsque nous avons été stocké à l'origine de leur mot de passe, et de les comparer

Quand je suis à l'aide de Concevoir avec bcrypt, il n'y a pas de sel de la colonne dans la base de données, donc je suis confus. Si le sel est aléatoire et ne sont pas stockées n'importe où, comment peut-on de manière fiable répétez le processus de hachage?

En bref, comment peut-bcrypt ont intégré dans les sels?

Answer 1

C'est bcrypt:

La génération aléatoire de sel. Un "coût" facteur a été pré-configuré. Recueillir un mot de passe.

Dériver une clé de chiffrement du mot de passe en utilisant le sel et le facteur de coût. L'utiliser pour crypter une chaîne connue. Stocker le coût, le sel, et le texte chiffré. Parce que ces trois éléments ont une longueur connue, il est facile de les enchaîner et de les stocker dans un seul champ, mais être en mesure de séparer les distingue plus tard.

Quand quelqu'un essaie de s'authentifier, de récupérer la stockées coût et le sel. Dériver une clé de mot de passe d'entrée. Chiffrer le même bien connu de la chaîne. Si l'généré le texte chiffré correspond à la stockées texte chiffré, le mot de passe est un match.

Bcrypt fonctionne de manière très similaire à plus traditionnels schémas basés sur des algorithmes comme PBKDF2. La principale différence dans l'utilisation d'un dérivé de la clé pour chiffrer connu en texte brut; d'autres régimes (raisonnablement) assumer la fonction de dérivation de clé est irréversible, et de stocker la clé dérivée directement.

---

Stockées dans la base de données, bcrypt "hash" pourrait ressembler à quelque chose comme ceci:

$2a$10$vI8aWBnW3fID.ZQ4/zo1G.q1lRps.9cGLcZEiGDMVr5yUP1KUOYTa

• 2a identifie l' bcrypt algorithme version qui a été utilisé.
• 10 est le facteur de coût; 2¹⁰ itérations de la fonction de dérivation de clé sont utilisés (ce qui n'est pas assez, par la manière. Je recommanderais un coût de 12 ou plus.)
• vI8aWBnW3fID.ZQ4/zo1G.q1lRps.9cGLcZEiGDMVr5yUP1KUOYTa est le sel et le texte chiffré, concaténés et encodé dans une modification de la Base-64. Les 22 premiers caractères de décodage de 16 octets de la valeur pour le sel. Les autres personnages sont de chiffrement de texte pour être comparé à des fins d'authentification.
• $ sont utilisés comme délimiteurs de la section d'en-tête de la table de hachage.

Cet exemple est tiré de la documentation pour Coda Hale ruby mise en œuvre.

Answer 2

Je crois que la phrase doit avoir été rédigé comme suit:

bcrypt a sels construit dans le générés hachages pour prévenir l'arc-en-ciel de la table des attaques.

L' bcrypt utilitaire lui-même ne semble pas à jour une liste de sels. Plutôt, les sels sont générées aléatoirement et ajoutés à la sortie de la fonction, de sorte qu'ils sont de rappeler plus tard (selon la Java de la mise en œuvre de l' bcrypt). Mettre une autre manière, le "hash" généré par bcrypt n'est pas juste de la valeur de hachage. C'est plutôt le hachage et le sel concaténées.