即使密码是服务器生成的,也要对密码进行哈希处理


Hashing passwords even when password is server-generated?

当服务器生成密码并且用户无法更改密码时,我是否应该对门户的用户进行哈希处理?逻辑:

  1. 用户不能在其他任何地方使用此密码,因为它是服务器生成的。

  2. 即使有人非法访问数据库,他们也可以更改密码并查看它,但这对他们来说毫无用处,因为它没有在其他任何地方使用。

我说的对吗?还是哈希仍然应该实现...?

安全性是分层完成的,每一层都旨在提高您不希望他们做的事情的成本。保安能防止抢劫吗?不,但它们提高了将一个承诺到大多数人不会打扰的成本。

哈希不能阻止人们入侵您的用户,但未加密的密码是公开邀请任何获得该数据访问权限的人自由登录您的用户帐户,只要您发现黑客攻击。

应该实现哈希,因为哈希是为了防止服务器泄露,而不是客户端/最终用户入侵。为了提高安全性,您在散列密码时也应该使用盐和密码散列算法。

理由是,如果您的服务器受到损害,无论是通过外部攻击(例如.SQL注入,SSH心脏出血等)还是内部攻击(例如恶意员工,如果有的话),那么可以检索密码或哈希。如果检索到它们,您希望使攻击者很难使用检索到的数据来危害您的系统。对于攻击者来说,带有盐的散列密码比他们可以与正确的用户名一起使用的明文密码更难使用。

    非哈希密码
  • :如果有人可以检索非哈希密码,则可以直接使用它们来模拟最终用户。
  • 不带盐的哈希密码:如果有人可以检索在没有盐的情况下创建的哈希密码,他们可以执行字典或暴力攻击,通过对字典中的单词或所有字符串进行哈希处理来查找密码。
  • 用盐散列密码
  • :如果您添加盐,那么检索到您的散列密码的攻击者还需要知道您的盐才能有效地攻击密码,例如通过字典攻击。

此外,在对密码进行哈希处理时,应使用专门为密码设计的哈希算法,例如 bcrypt,而不是像 SHA 这样的通用哈希算法。这是因为通用算法设计得非常快,使攻击者更容易执行字典或暴力攻击。像bcrypt这样的密码散列算法散列速度很慢,因此它会减慢攻击者的速度。

始终哈希密码永远不会以纯文本形式存储它们,即使您认为只有您会看到/使用它。