存储 bcrypt 哈希值
根据 PHP 的文档，bcrypt salt 是由
“$2a$”，两位数的成本参数，“$”，以及字母表中的 22 位数字“./0-9A-Za-z”
因此，如果我使用 crypt() 函数对我的密码进行哈希处理，得到的结果输出包括前 7 个字符（$2a$10$，如果 10 是成本参数）作为盐的一部分 - 并且，根据我在互联网上找到的所有示例，这个完整的输出被写入 db。
我想知道将这些第一个字符与其余的盐和加密数据一起存储有什么意义。它们的含义对我来说完全清楚，但我无法真正理解为什么这些信息应该与散列的其余部分一起写入。它们不是“只是”有关算法和计算的自适应成本的信息吗？那么存储此类应用程序相关信息有什么好处呢？而且（即使听起来很幼稚）为什么要将它们透露给最终可以获取我的数据库的攻击者？
According to PHP's doc, bcrypt salt are made of
"$2a$", a two digit cost parameter, "$", and 22 digits from the alphabet "./0-9A-Za-z"
So, if i use the crypt() function to hash my passwords, the resulting output include the first 7 chars ($2a$10$, if 10 is the cost parameter) as a part of the salt - and, according to all examples i was able to find across the internet, this complete output is written to db.
I'm wondering what's the point in storing those first characters with the rest of the salt and the encrypted data. Their meaning is fully clear to me, but i can't really understand why such informations should be written alongside the rest of the hash. Aren't they "just" informations about the algorithm and the adaptive cost of the computation? So what's the benefit in storing such application-related info? And (even if may sound childish) why disclosing them to an attacker which can eventually grab my database?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
原因是 crypt 的工作原理。它的设计使您可以执行以下操作
因此，通过存储所有内容，您不需要每次都重新创建盐字符串...
并且盐的目的不是保密。事实上，这并不意味着要保密。它的目的是衬托彩虹桌。请记住，如果他们可以获取您的数据库，那么他们也很有可能获得其他东西，因此将盐放在其他地方并不会真正给您带来太多好处。
此外，盐也起不了多大作用。 BCrypt 被设计为 CPU-Hard，这意味着暴力破解（即使知道盐）是不切实际的。这就是为什么你有一个成本参数。所以不用担心“隐藏”盐。只需将其与密码一起存储就可以了...
更不用说如果将来您想调整算法会发生什么？例如，假设您希望由于安装更好的硬件而增加成本参数。如果您没有将这些信息与密码一起存储，您存储的所有密码都将变得无效。这样，存储的每个密码都包含验证它所需的所有信息。这样，您可以检查是否有效登录，如果哈希值是当前默认值，如果不是，则重新哈希并使用新哈希值更新数据库。它可以防止与更新和改进哈希方法相关的问题......
The reason is because of how crypt works. It's designed so that you can do the following
So by storing everything, you don't need to recreate the salt string every time...
And the point of a salt is not to be secret. In fact, it is not meant to be secret. It's meant to foil rainbow tables. remember, if they can grab your database, the chances are high they can get other things as well, so putting the salt elsewhere isn't really going to give you much.
Besides, the salt won't help much. BCrypt is designed to be CPU-Hard, which means that brute-forcing (even with knowing the salt) is impractical. That's why you have a cost parameter. So don't worry about "hiding" the salt. Just store it along side the password and you'll be fine...
Not to mention that what happens if in the future you want to tweak your algorithm? For example, let's say you want to increase the cost parameter due to better hardware being installed. If you didn't store this information with the password, all of your stored passwords would become invalid. This way, each password stored has all the information necessary to verify it. That way, you can check on valid login if the hash is the current default, and if not rehash and update the database with the new one. It prevents the issues associated with updating and improving the hashing methods...