存储bcrypt哈希 [英] Storing bcrypt hashes

查看:114
本文介绍了存储bcrypt哈希的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

根据PHP的文档,bcrypt salt由


<$> $ 2a $,一个两位数的开销参数$组成, ,和字母表中的22位数字./0-9A-Za-z

所以,如果我使用crypt()函数来哈希我的密码,结果输出包括前7个字符($ 2a $ 10 $,如果10是成本参数)作为盐的一部分 - 根据我能够在互联网上找到的所有示例,完整的输出写入数据库。



我想知道将这些第一个字符与salt的其余部分和加密数据存储在一起是什么意思。他们的含义对我来说是完全清楚的,但我不明白为什么这些信息应该与其余的散列一起写。他们不是只是关于算法和计算的适应性成本的信息吗?那么存储这种与应用程序相关的信息有什么好处?而且(即使听起来可能幼稚)为什么要将它们泄露给最终能够抓取我的数据库的攻击者?
解决方案

原因是因为如何加密的作品。它的设计目的是让你可以执行以下操作:

$ p $ if($ hashedPassword == crypt($ rawPassword,$ hashedPassword)){
//已验证
}

因此,通过存储所有内容,您不需要每次重新创建盐串...

盐的点不是保密的。事实上,这并不意味着保密。这意味着箔彩虹表。请记住,如果他们能抓住你的数据库,那么他们可以获得其他东西的机会很高,所以把盐放在其他地方并不会真的给你带来太多的收益。



此外,盐不会有太大的帮助。 BCrypt被设计为CPU-Hard,这意味着暴力(即使知道盐)是不切实际的。这就是为什么你有一个 cost 参数。所以不要担心隐藏盐。只要把它放在密码的旁边,你就会好起来的......



更不用说,如果将来你想调整你的算法会发生什么?例如,假设您想增加成本参数,因为安装了更好的硬件。如果您未将此信息与密码一起存储,则您存储的所有密码都将失效。这样,每个存储的密码都具有验证它所需的全部信息。这样,如果哈希是当前的默认值,并且如果不重新哈希并使用新哈希来更新数据库,则可以检查有效的登录。它可以防止与更新和改进哈希方法相关的问题...


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?

解决方案

The reason is because of how crypt works. It's designed so that you can do the following

if ($hashedPassword == crypt($rawPassword, $hashedPassword)) {
    //Verified
}

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...

这篇关于存储bcrypt哈希的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆