Question Comment bcrypt peut-il avoir des sels intégrés?


L'article de Coda Hale "Comment stocker un mot de passe en toute sécurité" affirme que:

bcrypt a des sels intégrés pour empêcher les attaques de table arc-en-ciel.

Il cite ce papier, qui dit que dans la mise en œuvre d'OpenBSD bcrypt:

OpenBSD génère le sel bcrypt 128 bits d'un arcfour   (arc4random (3)) flux de clé, ensemencé avec des données aléatoires le noyau   recueille à partir des timings de l'appareil.

Je ne comprends pas comment cela peut fonctionner. Dans ma conception d'un sel:

  • Il doit être différent pour chaque mot de passe stocké, de sorte qu'une table arc-en-ciel séparée devrait être générée pour chaque
  • Il doit être stocké quelque part afin qu'il soit répétable: lorsqu'un utilisateur tente de se connecter, nous prenons la tentative de mot de passe, répétons la même procédure de hachage que nous avions lorsque nous avons enregistré le mot de passe et comparons

Lorsque j'utilise Devise (un gestionnaire de connexion Rails) avec bcrypt, il n'y a pas de colonne de sel dans la base de données, donc je suis confus. Si le sel est aléatoire et n'est stocké nulle part, comment pouvons-nous répéter le processus de hachage de manière fiable?

En bref, comment bcrypt peut-il avoir des sels incorporés??


450
2017-07-26 15:21


origine


Réponses:


C'est bcrypt:

Générer un sel aléatoire. Un facteur "coût" a été préconfiguré. Recueillir un mot de passe.

Dérivez une clé de chiffrement du mot de passe en utilisant le facteur sel et coût. Utilisez-le pour chiffrer une chaîne bien connue. le magasin le coût, sel, et texte chiffré. Parce que ces trois éléments ont une longueur connue, il est facile de les concaténer et de les stocker dans un seul champ, mais être capable de les séparer plus tard.

Lorsque quelqu'un essaie de s'authentifier, récupérez le coût et le sel stockés. Dérivez une clé du mot de passe d'entrée, du coût et du sel. Crypter la même chaîne bien connue. Si le texte de chiffrement généré correspond au texte chiffré stocké, le mot de passe correspond.

Bcrypt fonctionne de manière très similaire à des schémas plus traditionnels basés sur des algorithmes comme PBKDF2. La principale différence est son utilisation d'une clé dérivée pour crypter le texte brut connu; D'autres schémas supposent (raisonnablement) que la fonction de dérivation de clé est irréversible et stockent directement la clé dérivée.


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

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

C'est en fait trois champs, délimités par "$":

  • 2a identifie le bcrypt version de l'algorithme qui a été utilisée.
  • 10 est le facteur de coût; 2dix les itérations de la fonction de dérivation de la clé sont utilisées (ce qui n'est pas suffisant, en passant, 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 codés dans une base 64 modifiée. Les 22 premiers caractères décodent en une valeur de 16 octets pour le sel. Les caractères restants sont des textes chiffrés à comparer pour l'authentification.

Cet exemple est tiré du documentation pour l'implémentation de ruby ​​de Coda Hale.


592
2017-07-26 16:11



Je crois que cette phrase aurait dû être libellée comme suit:

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

le bcrypt l'utilité elle-même ne semble pas maintenir une liste de sels. Au contraire, les sels sont générés de façon aléatoire et ajoutés à la sortie de la fonction de sorte qu'ils sont rappelés plus tard (selon l'implémentation Java de bcrypt). En d'autres termes, le "hash" généré par bcrypt n'est pas juste le hachage. C'est plutôt le hash et le sel concaténé.


138
2017-07-26 15:34