swa*_*wag 2 encryption passwords hash
在线阅读了一些帖子和文章之后,似乎大多数(如果不是全部)人们都建议使用某种哈希算法来保证用户的密码安全,因为你不能解开它,这很好,但这就是我开始有一个我的情况有问题.
现在我处于修改用户密码保护方式的早期阶段.我们目前使用Sha512将散列密码存储在MySQL数据库中.根据我目前的理解,虽然哈希可能是安全的,因为它们不能反转(或者至少不那么容易),但是由于哈希具有固定长度而不管大小如何,因此也存在不安全性.原始输入,限制可能的哈希数,导致可能的Pidgeon Hole问题.
现在又出现了另一个我遇到问题的部分,特别是对我的情况.
我正在尝试为用户的密码添加一些功能,如果用户的密码与他们的最后三个密码太相似,则用户无法输入新密码.例如:如果他们的最后一个密码是password1234新密码xxxpasswordxxx,那么它就会失败.但是,根据我的理解,我无法添加此功能,因为我无法取消以前的密码来检查旧密码中的子字符串是否在新密码中.这将我带到整个加密/解密部分.
我一直在使用CBC加密模式查看AES 128,它似乎是一个可靠的选择,因为我并不太关心加密部分的并行化.另外,通过使用加密路径而不是散列路径,我实际上可以检查它们的最后三个密码是否与它们当前的密码相似!但是,存在的问题是首先能够看到用户的纯文本密码.
另外,我一直试图想办法为每个密码使用唯一密钥而不将其存储在我们的数据库中,因为我觉得这太不安全了.我可以使用静态随机密钥来输入所有密码,但我不确定这是不是一个好主意,即使我对所有密码使用唯一的IV.
总而言之,我的情况是:我希望能够阻止用户输入类似于旧密码的密码,此外还能真正提高密码存储的安全性.根据我目前的知识,我可以继续将密码存储为哈希,但我无法进行类似的密码检查或者我可以加密密码,这是不赞成的.
我显然不是这方面的专家,我知道我需要做更多的研究,但我想确保我开始朝着正确的方向前进.
关于第二段:哈希冲突绝对不是问题.对于哪种攻击场景,您认为这是一个问题？你应该停止抛出流行语,特别是关于安全性.
你的功能想法会失败,你是部分正确的.这是一个很好的想法,因为这个想法很糟糕.为什么你想要这个"功能" - 它只会惹恼用户并导致人们试图在最后使用数字来规避你的限制,包括月份或其他一些从版本到版本的增量.
加密密码很糟糕 - 期间.
一旦你可以解密它们,攻击也可以 - 故事结束.
您所描述的场景的个人经验:客户端有一个工具,您每两个月就被迫更改密码,我目前正在"password"10.我正在做每个人每隔X个月强制更改一次密码的警告 - 只需逐个改变相同的密码.我有一个非常好的密码(15个以上的字符,大写和小写,数字,特殊字符)以及为我设置帐户的任何网站选择密码的系统.强迫我更改密码会破坏我的"系统",因为现在我不能再一次又一次地在脑中生成密码,因为结果与前两个月网站强迫我设置的内容不符.如果该网站开始引入一些密码相似性限制,我可能会开始写下来.