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 cet article , qui dit que dans la mise en œuvre d'OpenBSD de bcrypt
:
OpenBSD génère le sel bcrypt 128 bits à partir d'un flux de clés arcfour (arc4random (3)), ensemencé avec des données aléatoires que le noyau recueille à partir des synchronisations des périphériques.
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 distincte devrait être générée pour chaque
- Il doit être stocké quelque part afin qu'il soit reproductible: lorsqu'un utilisateur essaie de se connecter, nous prenons sa tentative de mot de passe, répétons la même procédure de sel et de hachage que nous avons faite lorsque nous avons initialement stocké son 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 de manière fiable le processus de hachage?
En bref, comment bcrypt peut-il avoir des sels intégrés ?