具体问题
>使用整数唯一用户ID是否失效作为有效盐？ (crypt()只使用16位？)
>如果我只是一次又一次地运行sha256(),直到一秒钟用完,那会击败暴力攻击？
>如果我要问这些问题我应该用bcrypt吗？
讨论/说明：
目标是简单地说,如果我的用户的散列密码泄漏了他们：
>不会“容易”破解,
>破解一个密码不会暴露使用相同密码的其他用户).
我为#1读取的是哈希计算必须是昂贵的 – 取一秒或两秒来计算,也可能需要一点或内存(以阻止硬件解密).
bcrypt已经内置了这个内存,并且如果我理解正确,那么scrypt是更加面向未来的,并且包含最低内存使用要求.
但是,使用sha256()的结果多次,使用几秒钟,然后存储最后的循环计数与散列,以后检查提供的密码,同样有效的方法来吃饭时间？
对于#2,对每个密码使用唯一的盐是很重要的.什么还不清楚盐是如何随机(或大)的.如果目标是避免使用“mypassword”作为其密码的人使用相同的哈希,那么仅仅这样做是不够的：
hash = sha256_hex( unique_user_id + user_supplied_password );
甚至这个,虽然我不知道它买什么东西：
hash = sha256_hex( sha256( unique_user_id ) + user_supplied_password );
使用用户ID可以看到唯一的好处,除了我知道它是独一无二的,避免了不得不像哈希一样保存盐.没有什么优势.使用用户的ID作为盐有真正的问题吗？它不能完成#2吗？
我假设有人可以窃取我的用户的哈希密码,那么我必须假设他们可以得到任何他们想要的东西 – 包括生成哈希的源代码.那么,在哈希之前添加一个额外的随机字符串(相同的字符串)到密码有什么好处吗？那是：
# 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”,并在运行字典攻击时使用它,对吧？
有没有一个很好的理由使用bcrypt滚动我自己的如上所述？也许事实上,我提出这些问题是足够的理由？
BTW – 我只是计时一个现有的哈希函数和我的笔记本电脑,我可以生成约7000个哈希秒.不太常见的一两秒钟.
一些相关链接：
using sha256 as hashing and salting with user’s ID
解决方法
我对bcrypt的主要关注是,如果工作因素设置为高,那么由于多个用户尝试登录,因此您可以根据并发登录数量和系统资源调整系统. ..
盐仍然是必需的,它们的主要目的是为了防止离线攻击,如果盐的空间很大,那么对手将无法生成查找表,64位盐似乎有点低,bcrypt有128与工作因素相结合使得它对离线攻击造成了相当大的挑战…是的,盐应该是每个密码随机的,bcrypt会为你生成一个,如果你为每个密码使用相同的盐,那么你已经做了为对手强化使用在线攻击的所有密码.
如果您正确设置了工作因素,Bcrypt真的会发光,因为即使我得到了哈希,也就是说如果“对手”获得哈希值,那么这个工作因素让整个字典变得非常痛苦,需要多天,如果密码不在字典中,那么我真的很麻烦,因为一个暴力的攻击将是史诗般的,bcrypt的密码位空间相当大但是有限的:)
Sha256现在可能要花点时间了,但是最终电脑会越来越快,攻击就相当容易了,unix的人觉得crypt太慢了,这永远不会成为一个问题,今天我做了一个几秒钟内的在线攻击,数天的离线攻击,数周内的强力攻击(遍历整个密码位空间)…
>您希望盐尽可能大,随机使用数字,使我更容易迭代所有可能的ids.>多个sha256可能需要一秒钟的时间,但在道路上它将不再有效,计算机处理能力呈指数级增长,因此您需要可以配置的算法.>如果有更多的人这样做,我们不会有这么多的违规行为,你正在通过提问和做家庭作业来做正确的事情
