最佳实践是我们应该使用诸如 bcrpyt 之类的算法对用户密码进行哈希处理以保护用户,但是,鉴于以下条件,后端的哈希处理仍然重要吗?
- 密码由后端随机生成,具有足够的安全系数
- 用户将无法更改它
由于密码是我们随机生成的,用户不会在其他服务(如电子银行)上使用相同的密码,那么散列密码真的可以增加安全性吗?
最佳实践是我们应该使用诸如 bcrpyt 之类的算法对用户密码进行哈希处理以保护用户,但是,鉴于以下条件,后端的哈希处理仍然重要吗?
由于密码是我们随机生成的,用户不会在其他服务(如电子银行)上使用相同的密码,那么散列密码真的可以增加安全性吗?
哈希密码的关键在于,如果攻击者可以访问您的密码文件(通过侵入您的服务器、窃取备份媒体、入侵您的托管服务提供商等),他/她仍然无法从哈希中恢复密码并且以用户身份登录。
有两个级别:
您需要一些散列作为第二道防线,以便您存储在服务器上的内容(我称“服务器”是通过验证给定密码进行身份验证的系统)不足以实际模拟用户。这避免了部分只读破坏(例如,被盗的备份磁带)升级为更完整的读写访问。有关更长的讨论,请参阅此博客文章。
如果您对密码进行哈希处理,那么如果源密码具有低熵,您可能需要使用密码哈希函数。人类用户选择的密码具有低熵。如果您“随机”生成密码,那么您可能会获得高熵密码。或不。通过以加密安全 PRNG 为基础的已知系统过程生成密码的好处在于,您可以计算熵,而不仅仅是估计它。但是,您仍然必须确保获得足够的内容。
例如,如果您将密码生成为 10 个随机字符(小写和大写字母以及数字)的序列,并且所有字符都是统一选择且彼此独立的,则有 62 10 个可能的密码,每个密码都有被选中的概率比其他任何人都相同。然后熵等于 log(62 10 )(以 2 为底的对数),即 59.54 位。这还不错,但如果使用简单的哈希函数,可能还是有点太低了,因为一个好的 GPU每秒可以运行数十亿次 MD5 或 SHA-1。然后,您应该添加盐和迭代,即使用 bcrypt(但小的迭代计数已经可以了)。
如果您的密码至少有 80 位熵,那么您可以认为它们足够强大,甚至可以击败富有而坚定的攻击者,并且您可以使用简单的散列(即您可以使用简单的散列调用,也可以不使用使用盐)。使用随机字母和数字,这将转换为14 个字符。我坚持认为,只有当这 14 个字符是随机、统一且彼此独立地选择时,这才是正确的。这些是您可以使用密码生成器来满足的要求,但您不能从用户选择的密码中实际期望它们。
您应该像对待任何其他密码一样对待它。
您不能保证用户不会在其他系统上重复使用您的密码,除非您对其进行控制 - 例如,当我必须为我的新 ISP 邮件服务器选择密码时,我使用了从以前系统自动生成的密码,这样我会记住它(比计划的更长的临时时间)。
如果您强制用户使用随机生成的密码,他们仍然有可能将其用于其他用途 - 相当多的人会将其写下来或以纯文本形式存储在某处,并且更容易使该列表保持简短。您不能假设您的用户甚至对密码安全性有 1/2 的线索,即使是那些知道的人也可能没有足够重视您的服务而不会打扰到体面的安全性。
在给定的场景中,当攻击者获得对密码存储的读取访问权限,但没有写入访问权限或对任何其他数据的访问权限时,拥有散列密码可以保护您。在这种情况下,他们可以使用密码登录并访问更多数据。
当攻击者获得对密码存储的写访问权时,他们将能够用他们自己的密码替换散列,因此在这种情况下散列不会保护你。
此外,当密码数据库被泄露时,您可以假设服务器上的任何其他数据也被泄露,因此攻击者甚至可能没有登录的理由。