选择哈希或加密密码的困境

Question

在阅读了一些在线文章和文章之后，似乎大多数人（如果不是全部的话）建议使用某种哈希算法来保持用户的密码安全，因为您无法解决它，这很好，但那是我开始对我的情况有问题的地方。

现在我正处于修改我们确保用户密码方式的初期阶段。我们目前使用Sha512将密码密码存储在我们的MySQL DB中。根据我目前的理解，虽然散列可能是安全的，因为它们不能相反（或者至少不那么容易），但它也是不安全的，因为有可能发生冲突，因为散列具有固定的长度，不管大小如何原始输入，这限制了可能的散列数量，从而导致可能的Pidgeon Hole问题。

现在来了另一个我有问题的部分，特别是对于我的情况。

我想添加一些功能，我们的用户的密码，如果用户不能输入一个新的密码，如果它是过于相似，他们的最后三个密码。例如：如果他们的最后一个密码是password1234而他们的新密码是xxxpasswordxxx，那么它会失败。但是，从我的理解来看，我不可能添加此功能，因为我无法解决他们以前的密码，以检查旧密码中是否有子字符串在其新密码中。这将我带到整个加密/解密部分。

我一直在寻找AES 128使用CBC加密模式，它似乎是一个可靠的选择，因为我真的不在乎在加密部分的并行化。除此之外，通过使用加密路线而不是散列路线，我实际上可以检查他们的最后三个密码是否与他们当前的密码相似！但是，首先可以看到用户的纯文本密码的问题是存在的。

此外，我一直在想办法为每个单独的密码使用唯一密钥，而不将它存储在我们的数据库中，因为我觉得这太不安全了。我可以对所有密码使用静态随机密钥，但我不确定这是否是一个好主意，即使我为所有密码使用了独特的IV。

因此，总结我的情况是这样的： 我希望能够防止用户输入类似于他们的旧密码的密码，除了实际上提高密码存储的安全性。根据我目前的知识，我可以继续将密码存储为散列，但我无法进行类似的密码检查，或者我可以对密码进行加密，这是令人不悦的。

我显然不是这方面的专家，而且我知道我需要做更多的研究，但我想确保自己是从正确的方向开始的。

Answer 1

关于第二段：散列冲突是绝对不是有问题。对于哪种攻击情形，你认为这是一个问题？你应该停止投入流行语，特别是在安全方面。

你的功能主意会失败，这是你的部分权利。这是一个很好的想法，因为这个想法很糟糕。为什么你想要这个“功能” - 它只会让用户恼火，并导致人们试图绕过使用数字的限制，包括月份或其他版本的增加。

加密密码不好 - 期间。
只要你可以解密他们，攻击可以作为故事的结尾。

---

几乎你所描述的情景的个人体验：客户端有一个工具，您被迫更改密码每2个月，我目前是"password"10。当我每X个月强制更改密码时，我正在做每个人都警告的事情 - 只需逐个更改相同的密码即可。我有一个非常好的密码（15个以上的字符，大写和小写，数字，特殊字符），以及为我设置帐户的任何网站选择密码的系统。强迫我改变密码破坏了我的“系统”，因为现在我不能再一次又一次地在头上生成密码，因为结果将不符合网站在前两个月后设置的密码。如果网站开始引入一些密码相似性限制，我可能会开始写下来。

Answer 2

要保密的方式，你必须哈希密码加盐。

对于每个用户，您随机选择一个盐，您为每个用户保存数据库中的salt。 您存储在数据库哈希（密码+盐）。

当您必须检查用户密码时，只需添加盐，散列两者并检查数据库。 如果用户更改密码，您也可以更改盐。

之后，您可以根据安全级别选择算法或其他算法，SHA2似乎是一个好的开始。

Answer 3

为什么不继续使用散列，但要求用户在更改为新密码时输入旧密码，这样您就可以验证旧密码以授权更改密码，然后比较纯文本版本在进行更改之前是否有相似之处？

Answer 4

当您保留散列密码时，您无法检查相似的密码，但可以防止它们重复使用之前使用过的密码。通过保留旧的（希望是咸的！）密码，可以将散列（new_password + old_salt [i]）与旧密码的salted_hash [i]进行比较。如果它们相同，则用户重新使用旧密码。

我完全同意其他哈希碰撞不是问题。您正计划使用SHA512，即攻击者必须与之竞争的512位随机性。唯一可以破解的方法是使用rainbow tables，并且使用腌过的哈希来保护自己免受攻击（即，即使密码相同，腌制的哈希将导致不同的哈希值;如果攻击者得到知道盐和散列，所以你可以在一个位置存储salt + salted_hash）。

出于安全原因，我会抛弃“类似密码”的东西。如果攻击者获得了一堆密码，则更改是数据库中存在许多错误的密码。使用启发式和字典式攻击，他会很好地改变猜测你的加密密钥 - >立即解锁所有用户的所有密码。

密码的唯一安全方式是如果存储它们的系统的操作员也无法恢复它们。其他任何事情只是下一个0天的bug等待被利用。

Answer 5

目前使用SHA512

SHA-512是太快存储在我们的MySQL数据库的散列密码。任何获取密码哈希的攻击者都可以通过哈希快速运行密码猜测。你需要一个缓慢的算法，所以每个猜测都需要数千倍的时间。但是，由于您也需要对这些密码进行散列，因此您需要选择一个不会使系统过载的值，或者更糟糕的是，测试用户的耐心。使用bcrypt（单独）或PBKDF2与SHA-512（尽管SHA-1 HMAC绰绰有余）结合使用。

它也是在不安全的有可能碰撞

SHA-512的碰撞性是没有问题的，直到你的系统内接近2个用户。由于这个星球上的人数甚至没有，我可以肯定地说你的系统会好的。

选择要么散列或加密密码

如果你需要一个理由去与前者的困境有一个看看details of the Adobe breach。他们正在加密密码而不是散列。 TLDR;灾害。如果您的系统尺寸适中，则不需要媒体就您的系统提供任何类似的内容。做好事情 - 使用PBKDF2或bcrypt - 这样您就可以使用行业认可的方法来关注用户，并且不会因为您的密码存储方案而受到批评。

通过使用加密航线，而不是一个散列路线，我可以 真的这样做检查，看看他们的最后三个密码 相似，他们目前的一个

好，因为用户（希望）可以输入他们以前的密码作为额外的身份验证检查以更改他们的密码，您可以在此处比较他们的密码，因为您将以明文形式输入密码。例如

old password != new password 
lowercase'd letters in old password != lowercase'd letters in new password 
adding up all numbers in new password > adding up all numbers in old password + 2 || adding up all numbers in new password < adding up all numbers in old password - 2 

也许你想定义一些其他规则来防止密码相似性。如果这些规则适用于从第一个密码到第二个密码，然后是第二个密码到第三个密码的更改，则用户可能会习惯您的规则，并且可能不太可能使他们的第三个密码与他们的第一个密码过于相似。您还可以保留一个密码历史记录表，用于存储其以前的X密码（例如四个）的bcrypt哈希，并进行绝对比较以确保它们不会切换回以前使用的密码。我不会保留超过四个，以防万一他们以前的任何密码足够弱，无法破解并在其他网站上重复使用，因为系统上的任何破坏都可能暴露他们，并且如上所述，检查这些密码会很慢处理。但是，您可以继续确保用户不会选择任何违反密码的密码，方法是将常用密码加载到系统的黑名单中。

密码的加密是一个坏主意，并且对所有以前的密码进行模糊匹配的安全优势并没有超过双向加密活跃的安全风险（在我看来）。