问题描述
Coda Hale 的文章 如何安全地存储密码" 声称:
Coda Hale's article "How To Safely Store a Password" claims that:
bcrypt 内置了盐来防止彩虹表攻击.
bcrypt has salts built-in to prevent rainbow table attacks.
他引用了这篇论文，其中说在 OpenBSD 的 bcrypt 实现中:
He cites this paper, which says that in OpenBSD's implementation of bcrypt:
OpenBSD 从 arcfour 生成 128 位 bcrypt salt(arc4random(3)) 密钥流，用随机数据播种到内核从设备计时收集.
OpenBSD generates the 128-bit bcrypt salt from an arcfour (arc4random(3)) key stream, seeded with random data the kernel collects from device timings.
我不明白这是如何工作的.在我的盐概念中:
I don't understand how this can work. In my conception of a salt:
- 每个存储的密码都需要不同，因此必须为每个密码生成单独的彩虹表
- 需要将其存储在某处以使其可重复:当用户尝试登录时，我们尝试输入他们的密码，重复我们最初存储他们的密码时所做的相同的盐和哈希过程，并进行比较
当我在 bcrypt 中使用 Devise(一个 Rails 登录管理器)时，数据库中没有 salt 列，所以我很困惑.如果 salt 是随机的并且没有存储在任何地方，我们如何可靠地重复哈希过程?
When I'm using Devise (a Rails login manager) with bcrypt, there is no salt column in the database, so I'm confused. If the salt is random and not stored anywhere, how can we reliably repeat the hashing process?
简而言之，bcrypt 怎么可能有内置盐?
推荐答案
这是 bcrypt:
生成随机盐.成本"因素已预先配置.收集密码.
Generate a random salt. A "cost" factor has been pre-configured. Collect a password.
使用盐和成本因素从密码中导出加密密钥.用它来加密一个众所周知的字符串.存储成本、盐和密文.因为这三个元素的长度已知，所以很容易将它们连接起来并将它们存储在一个字段中，但稍后可以将它们分开.
Derive an encryption key from the password using the salt and cost factor. Use it to encrypt a well-known string. Store the cost, salt, and cipher text. Because these three elements have a known length, it's easy to concatenate them and store them in a single field, yet be able to split them apart later.
当有人尝试进行身份验证时，检索存储的成本和盐.从输入的密码、成本和盐中派生出一个密钥.加密同一个众所周知的字符串.如果生成的密文与存储的密文匹配，则密码匹配.
When someone tries to authenticate, retrieve the stored cost and salt. Derive a key from the input password, cost and salt. Encrypt the same well-known string. If the generated cipher text matches the stored cipher text, the password is a match.
Bcrypt 的运行方式与基于 PBKDF2 等算法的更传统方案非常相似.主要区别在于它使用派生密钥来加密已知的纯文本；其他方案(合理地)假设密钥派生函数是不可逆的，直接存储派生的密钥.
Bcrypt operates in a very similar manner to more traditional schemes based on algorithms like PBKDF2. The main difference is its use of a derived key to encrypt known plain text; other schemes (reasonably) assume the key derivation function is irreversible, and store the derived key directly.
存储在数据库中，bcrypt哈希"可能看起来像这样:
Stored in the database, a bcrypt "hash" might look something like this:
$2a$10$vI8aWBnW3fID.ZQ4/zo1G.q1lRps.9cGLcZEiGDMVr5yUP1KUOYTa
$2a$10$vI8aWBnW3fID.ZQ4/zo1G.q1lRps.9cGLcZEiGDMVr5yUP1KUOYTa
这实际上是三个字段，以$"分隔:
This is actually three fields, delimited by "$":
2a标识使用的bcrypt算法版本.10是成本因素；使用了密钥派生函数的 210 次迭代(顺便说一下，这还不够.我建议成本为 12 或更多.)vI8aWBnW3fID.ZQ4/zo1G.q1lRps.9cGLcZEiGDMVr5yUP1KUOYTa是盐和密文，以修改后的 Base-64 连接和编码.前 22 个字符解码为盐的 16 字节值.其余字符为密文，用于验证比较.
2aidentifies thebcryptalgorithm version that was used.10is the cost factor; 210 iterations of the key derivation function are used (which is not enough, by the way. I'd recommend a cost of 12 or more.)vI8aWBnW3fID.ZQ4/zo1G.q1lRps.9cGLcZEiGDMVr5yUP1KUOYTais the salt and the cipher text, concatenated and encoded in a modified Base-64. The first 22 characters decode to a 16-byte value for the salt. The remaining characters are cipher text to be compared for authentication.
此示例取自 Coda Hale 的 ruby 实现文档.
这篇关于bcrypt 如何内置盐?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，WP2