将散列密码保存在 cookie 中真的很危险吗？答案

【问题标题】：Is it really dangerous to save hashed password in cookies?将散列密码保存在 cookie 中真的很危险吗？
【发布时间】：2011-12-27 13:43:05
【问题描述】：

关于在 cookie 中保存哈希密码的安全风险有很多讨论，因为在访问用户的计算机时，黑客可以使用保存的密码登录。如果黑客可以访问用户的计算机，他可以获取密码，因为浏览器也会在本地保存密码（当然是加密的）。 cookie中设置的密码与浏览器保存的密码有什么区别？

出于显而易见的原因，应发送临时 GUID 而不是密码。无论如何，我相信限制对记录 IP 的访问可以为攻击者使用本地保存的 GUID 关闭大门。当然，它会限制记录周期的长度，因为 IP 通常是动态的并且会定期更改；但我认为值得其明显的安全性。有什么想法吗？

【问题讨论】：

唯一使散列密码安全的事情是散列发生在服务器上。
我知道你的意思；但是这里的哈希密码或 GUID 的目的是为了长期，不能更改尝试和错误攻击。
Do not use a guid as a session token.

标签： security authentication cookies logging passwords

【解决方案1】：

在访问用户的计算机后，黑客可以使用保存的密码。如果黑客可以访问用户的计算机，他可以获取密码，因为浏览器也会在本地保存密码（加密当然）。

不知道你在这里的意思。如果您要求 IE 记住您的网站密码，并且有人拥有您计算机的密码并且可以使用您的 IE，那么是的，他可以使用您的密码登录。但这与散列或 cookie 等无关。

首先，无法检索散列密码。所以如果有人知道你密码的哈希值，他就不知道你的密码。

当您登录请求密码的站点时，您提供的密码是加密发送的。标准做法是将用户的密码存储为哈希，即不是密码本身。因此，您输入密码，接收服务器会将哈希值与存储的哈希值进行比较。

现在与您关于在 cookie 中发送散列密码的问题有关，这与会话管理有关。 IE。判断用户是否已经成功登录。
恕我直言，在使用纯 HTTP 时仅使用散列密码来确定用户是否已经登录不是一个好主意。

但如果这是你问的，那就是另一个话题了。
IE。如何最好地通过 HTTP 连接进行会话管理

【讨论】：

【解决方案2】：

是的，在 cookie 中使用散列密码不太安全。将它保存在浏览器中和通过网络发送它是有区别的：除非你总是使用 SSL，否则攻击者不需要访问机器来从请求中读取 cookie .

发送随机值更安全，因为这样与用户的实际密码无关：忘记随机值可以使会话过期，而无需让用户更改密码。此外，如果攻击者确实从 cookie 中获取了散列值，他们可能会恢复实际密码（如果这是发送的内容）。

【讨论】：

不可能从哈希值中恢复密码。哈希函数是单向函数。如果它是一个非常糟糕的函数并且攻击者进行了一些字典攻击，它可能会找到一个产生相同哈希值的字符串。但是你把它放在你的答案中的方式不清楚你的最后一条语句是什么意思
通常是好的散列函数的函数会使散列密码的函数变差，因为它们是为速度而设计的。例如，攻击使用 MD5 散列的低质量密码已变得切实可行。所以我坚持我的“可能”，尽管我承认我并没有那么清楚。
我不确定我明白你的意思good hash functions make bad functions for hashing passwords, as they are designed for speed.o 你的意思是一个用于密码的函数，预计会很快吗？
我的意思是哈希函数运行得越快，暴力破解任何特定密码所需的时间就越少。像 bcrypt 这样的方案是可调的，因此您可以确保验证密码需要很长时间，这意味着暴力破解需要更长的时间。见codahale.com/how-to-safely-store-a-password

【解决方案3】：

我想您希望在 cookie 中存储散列密码的原因是创建一个“记住我”cookie。所以你需要一个秘密的cookie值，这样其他人就不能轻易猜到它。任何有权访问此值的人都可以作为此用户登录，因此它实际上是一个“额外密码”。

这里涉及两个风险：

最重要的是密码泄露的风险。这不仅会使您的网站面临风险，而且可能还会使其他网站面临风险。大多数用户重复使用他们的密码，密码可能会让入侵者访问用户的电子邮件帐户和网络银行。有权访问散列值的人可能会使用蛮力或彩虹表来发现原始密码（彩虹表是预先计算的散列的长列表）。彩虹表可轻松用于最多 8 个字符甚至更长的密码。您可以通过对密码进行加盐来避免这种情况，即在创建哈希之前它超过 20 个字符（请记住将加盐也存储在 cookie 中）。使用安全散列算法计算的正确加盐的密码散列应该是非常安全的。

另一个风险与用户必须更改其原始密码以使散列密码字符串无效的事实有关。一旦打开，用户就不可能真正关闭此功能。当他取消选中“记住我”按钮时，您可以删除 cookie，但如果 cookie 已经被泄露，这将无效。如果他的电脑被盗了怎么办？如果用户在一台计算机上选中了此按钮，则他必须有权访问该计算机才能禁用此功能。

【讨论】：

【解决方案4】：

您应该要求用户重新输入密码的时间：

当他们尝试更改密码时。
当他们尝试更改电子邮件地址时。
当他们尝试更改其安全信息（任何可用于恢复其密码的信息，包括用户名、电子邮件地址、安全问题等）时。
当他们尝试访问高度安全的帐户信息并且超过 15 分钟左右没有输入密码时（如果所有信息都高度安全，您应该将其直接注销以使其不活动）。亚马逊经常这样做。

保存散列密码会降低效率。

顺便说一句，您应该已经在使用安全的 cookie（不会通过 HTTP 传输）、HttpOnly（不能通过 javascript 访问）来防止 XSS 攻击。当然，如果有人完全破解了这个人的机器，他们只会安装一个键盘记录器。

【讨论】：