Web 应用程序密码:bcrypt 和 SHA256(和 scrypt) [英] Web app passwords: bcrypt and SHA256 (and scrypt)
问题描述
在最近(例如 LinkedIn)关于密码的所有讨论中，我正在研究密码哈希实现.在喝了两杯咖啡和早上阅读之后，我不再是一个密码学家了，就像我刚开始时一样.而且我真的不想假装我是.
With all the recent (e.g. LinkedIn) discussions of passwords I'm looking at password hashing implementations. After two cups of coffee and a morning reading I'm no more a cryptographer than when I started. And I really don't want to pretend that I am.
使用整数唯一用户 ID 作为有效盐会失败吗?(crypt() 只使用 16 位?)
如果我只是在哈希上一遍又一遍地运行 sha256() 直到用完一秒钟，这是否会击败暴力攻击?
如果我必须问这些问题，我应该使用 bcrypt 吗?
讨论/解释:
目标很简单，如果我的用户的散列密码被泄露，他们:
Discussion/Explanation:
The goal is simply if my user's hashed passwords were leaked they:
- 不会容易"破解，
- 破解一个密码不会暴露使用相同密码的其他用户).
我读到 #1 的内容是哈希计算必须很昂贵——比如说，需要一两秒来计算，并且可能需要一点或内存(以阻止硬件解密).
What I've read for #1 is the the hash computation must be expensive -- taking, say, a second or two to calculate and maybe requiring a bit or memory (to thwart hardware decryption).
bcrypt 内置了这个功能，如果我理解正确的话，scrypt 更具前瞻性，并且包含最低内存使用要求.
bcrypt has this built in, and scrypt, if I understand correctly, is more future-proof and includes a minimum memory usage requirement.
但是，通过重新散列"sha256() 的结果多次以用完几秒钟，然后将最终循环计数与散列一起存储以供以后检查提供的密码?
But, is it an equally effective approach to eat time by "rehashing" the result of sha256() as many times as needed to use up a few seconds and then store the final loop count with the hash for later checking a provided password?
对于#2，为每个密码使用唯一的盐很重要.尚不清楚盐必须有多随机(或大).如果目标是避免使用mypassword"作为密码的每个人都拥有相同的哈希值，那么仅仅这样做还不够吗?:
For #2, using a unique salt for every password is important. What's not been clear is how random (or large) the salt must be. If the goal is to avoid everyone that uses "mypassword" as their password from having the same hash is it not enough to simply do this?:
hash = sha256_hex( unique_user_id + user_supplied_password );
甚至这个，虽然我不确定它能给我带来什么:
or even this, although I'm not sure it buys me anything:
hash = sha256_hex( sha256( unique_user_id ) + user_supplied_password );
除了我知道它是独一无二的之外，我可以从使用用户 ID 中看到的唯一好处是避免将盐与哈希一起保存.没有太大的优势.使用用户 ID 作为盐是否存在真正的问题?它没有完成#2吗?
The only benefit I can see from using the user's ID, besides I know it is unique, is avoiding having to save the salt along with the hash. Not much of an advantage. Is there a real problem with using a user's ID as the salt? Does it not accomplish #2?
我假设如果有人可以窃取我用户的散列密码，那么我必须假设他们可以得到他们想要的任何东西——包括生成散列的源代码.那么，在散列之前向密码添加一个额外的随机字符串(相同的字符串)有什么好处吗?那就是:
I assume if someone can steal my user's hashed passwords then I must assume they can get whatever they want -- including the source code that generates the hash. So, is there any benefit to adding an extra random string (the same string) to the password before hashing? That is:
# app_wide_string = one-time generated, random 64 7-bit *character* string.
hash = sha256_hex( unique_user_id + app_wide_string + user_supplied_password );
我看到了这个建议，但我不明白我从每个用户的盐中获得了什么.如果有人想暴力破解攻击，他们会知道app_wide_string"并在运行字典攻击时使用它，对吧?
I have seen that suggested, but I don't understand what I gain from that over the per-user salt. If someone wanted to brute-force the attack they would know that "app_wide_string" and use that when running their dictionary attack, right?
如上所述，是否有充分的理由使用 bcrypt 而不是我自己的滚动?也许我问这些问题的理由就足够了?
Is there a good reason to use bcrypt over rolling my own as described above? Maybe the fact that I'm asking these questions is reason enough?
顺便说一句——我刚刚在我的笔记本电脑上计时了一个现有的哈希函数，我每秒可以生成大约 7000 个哈希值.不是通常建议的一两秒.
BTW -- I just timed an existing hashing function I have and on my laptop and I can generate about 7000 hashes a second. Not quite the one or two seconds that are often suggested.
一些相关链接:
推荐答案
Bcrypt 很棒，因为您可以将工作因子从 4 调整到 31，每个增量都会创建一个指数所需的时间，我实际上已经绘制了它，在工作中14 倍，它已经占用了一秒钟，因此随着计算机变得越来越快，您只需要更改一个参数，当然还需要更新您的密码哈希...
Bcrypt is great because you can tune the work factor from 4 to 31, each increment creates an exponentional required time, I've actually graphed it, at a work factor of 14 it's already taking over a second, so as computers get faster and faster you only need to change one parameter, and of course update your password hashes ...
我对 bcrypt 的主要担心是，如果工作系数设置为高，那么它可能会在多个用户尝试登录时使您的系统过载，因此您可以调整它，具体取决于并发登录的数量和资源你的系统...
My main concern with bcrypt is that if the work factor is set to high, then it may overload your system as multiple users are trying to login so you have tune it, depending on the number of of concurrent logins and the resources of your system ...
盐还是需要的，主要目的是阻止离线攻击，如果盐空间太大，那么对手将无法生成查找表，64位盐似乎有点低，bcrypt 有 128 位盐，加上工作因素，这对于离线攻击来说是一个很大的挑战……是的，每个密码的盐应该是随机的，bcrypt 会为你生成一个，如果你对每个密码使用相同的盐，那么你使攻击者更容易通过在线攻击破解所有密码.
Salts are still required, their main purpose is to deterred off-line attacks, if the salt space is to large, then the adversary won't be able to generate the look up table, 64 bit salt seems a bit low, bcrypt has 128 bit salts coupled with the work factor makes it quite a challenge for offline attacks ... and yes the salt should be random for each password, bcrypt will generate one for you, if you use the same salt for each password then you have made it eassier for the adversary to comprimised all the passwords using an online attack.
如果你正确设置了工作因子，Bcrypt 真的很适合在线攻击，因为即使我得到了哈希值，意思是说如果对手"得到了哈希值，工作因子也会让通过整个字典，需要多天，如果密码不在字典中，那么我真的有麻烦了，因为暴力攻击将是史诗般的，bcrypt 的密码位空间虽然有限但相当大:)
Bcrypt really shines for online attacks, if you have set the work factor properly, because even if I get the hash, meant to say if the 'adversary' gets the hash, the work factor makes it really painful to go through an entire dictionary, taking multiple days and if the password isn't in the dictionary, then I'm really in trouble cause a brute force attack will be epic, the password bit space for bcrypt is quite large though finite :)
Sha256 现在可能需要一些时间，但最终计算机会变得越来越快，并且很容易受到攻击，unix 人认为 crypt 太慢了，这绝不会成为问题，今天我已经在几秒钟内完成了一次在线攻击，在几天内完成了离线攻击，在几周内完成了一次暴力攻击(遍历整个密码位空间)......
Sha256 may be taking a bit of time now, but eventually computers will get faster and faster and it'll be fairly easy for attacks, the unix guys thought crypt was so slow it would have never being an issue, and today I have done an online attack in seconds, offline attack in days, a brute force attack (going through the entire password bit space) in weeks ...
- 您希望盐尽可能大且随机，仅使用数字使我更容易迭代所有可能的 id.
- 现在多个 sha256 可能需要一秒钟，但以后它不再有效，计算机处理能力呈指数级增长，因此您需要一种可以这样配置的算法.
- 通过提问和做功课，你是在做正确的事，如果有更多的人这样做，我们就不会有这么多违规行为
这篇关于Web 应用程序密码:bcrypt 和 SHA256(和 scrypt)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
