是否建议将散列密码存储在 cookie 中？答案

【问题标题】：Is it advisable to store a hashed password in a cookie?是否建议将散列密码存储在 cookie 中？
【发布时间】：2011-01-22 13:59:59
【问题描述】：

我希望用户能够在我的网站上选择“记住我”框，这样他们就不必每次来时都登录。所以，我需要在 cookie 中存储一个唯一 ID 来识别它们。使用 sha512 和 PHP 中的长盐对密码进行哈希处理并将该值存储在 cookie 中是否安全？如果 cookie 被盗，他们的密码会有风险吗？显然它必须以某种方式连接到他们的密码，否则如果 cookie 值被猜到或被盗，用户将无法阻止其他人登录。

另外，是否建议使用 GUID 作为唯一标识符？

谢谢，本

【问题讨论】：

您不需要存储密码来“记住”用户，对吗？
@o.k.w：它被用来重新认证用户。

标签： security encryption cookies hash

【解决方案1】：

好的算法和大盐的风险很低，但为什么要冒任何不必要的风险呢？

如果您只需要识别用户，则存储可以唯一识别用户的内容，例如 guid 以及其他存储的验证码（不是他们的密码，一些随机长字符串）。我不会单独使用 guid，因为它不是一种安全的身份验证方法。

【讨论】：

建议在更改密码时删除或修改此“随机长字符串”，以免用户（或拥有上述 cookie 的人）在密码已更改（或用户取消选择记住我，或...）
“随机长字符串”应该比密码更改时更频繁地过期，最好是在每次登录时。
字符串指向一个用户。它与身份验证无关。只要您想使缓存的凭据过期，您就可以将其删除，这与更改密码无关。
@Sam 同意； 技术上缓存的标识与密码的当前值无关。然而，有点像当有人改变他们家门上的锁时，他/她期望任何其他进入方式（如地图下的隐藏钥匙，即使这样的类比如果有缺陷）也会如此无效。这种期望会进入虚拟世界，这就是为什么取消缓存的 id 可能是一个好习惯。
@sam, -1 泄露密码哈希总是一个漏洞。

【解决方案2】：

请记住，密码的哈希值实际上与他们的密码相同。窃取哈希值的人对用户帐户的访问权限与窃取密码的权限相同。因此，不建议将用户密码的哈希值存储在 cookie 中，除非有一些其他信息不与 cookie 一起存储用于身份验证（即 2-因素认证）。

【讨论】：

+1 完全正确，否则首先对密码进行哈希处理有什么意义？它旨在延迟攻击者！
这当然假设攻击者知道使用什么散列算法以及是否涉及盐......仍然不建议
散列密码很难恢复，而且由于许多人在其他网站上也使用相同的密码，这就是公开一项服务和公开许多其他页面的凭据之间的区别:)跨度>
不会投反对票，但我不同意“实际上相同”的部分。大多数登录机制（例如基于表单的身份验证）将需要密码的纯文本版本（当然通过 SSL 发送）才能实际登录，而不是哈希版本。当然，如果他们知道哈希算法，他们可以使用蛮力方法逆向工作并相当快地创建 PW。但是，如果您创建了哈希服务器端，那么希望服务器代码是安全的并且他们不知道盐。此外，PiotrK 有一个很好的观点。
@eselk：我不确定你是否理解这个问题。 OP 想知道将密码哈希存储在 cookie 中并使用它进行身份验证是否安全。如果他这样做了，哈希就变成了一个复杂的明文密码。获得哈希的攻击者不必向后工作以获取密码，因为他们不需要它。

【解决方案3】：

在 cookie 中包含某种“密码”和用户 ID（以防止用户将 uid 更改为另一个用户的用户 ID）并没有什么坏处，只是不要使“密码”相同作为实际用户的密码。

并且仅仅因为它是一个哈希并不一定意味着它是单向的（嗯，根据定义它确实如此，但是有一些实用程序可以生成 MD5 明文，我猜它发生在其他人身上只是时间问题） .我会散列某种辅助密码。

【讨论】：

【解决方案4】：

Here 是一篇关于这个主题的优秀文章。您问题的许多答案都涉及其中概述的技术。

【讨论】：

感谢克里斯，这篇文章真的很棒

【解决方案5】：

另一种方法是使用 cookie 作为仅用于间接数据的加密存储。您需要某种未加密的标识符，该标识符将用作指向应用程序数据库中密钥（或派生密钥所需的信息）的指针，然后是由从标识符获得的密钥加密的 blob，该标识符本身将包含对会话进行身份验证的某种一次性可用标识符。

鉴于以下假设：

您的数据库是安全的（例如，您的应用程序可以访问它，但您的用户不能直接这样做，并且还假设应用程序已针对 SQL 注入进行了验证）
你的盐很浓；也就是说，足够高的熵，即使密码已知，尝试破解加盐密码也是不可行的

那么这将提供一种方法，通过该方法可以合理地确定会话不会以任何方式被劫持或窃取。也就是说，复制的 cookie 的用处有限，因为用户在 cookie 被盗和被攻击者使用之间一定没有使用过。

虽然这可以防止重放，但也意味着如果有人确实在正确的时间窃取了 cookie，并且还设法在原始合法用户之前使用它，那么攻击者现在就可以控制会话.可以将会话限制到 IP 地址以减轻这种风险（在某种程度上；如果用户和攻击者都在同一个 NAT 后面，这是任何家庭或中小型企业网络中最有可能出现的情况）那么这一点没有实际意义，因为无论如何IP地址似乎都是一样的。同样有用的可能是限制当前的用户代理（尽管如果用户更新他们的浏览器并且会话在浏览器关闭时没有过期，这可能会意外中断），或者找到一些可以识别用户所在计算机的方法足够好，可以合理确定用户没有将 cookie 从一个系统移动到下一个系统。由于没有使用一些二进制插件（Flash 或 Silver/Moonlight），我不确定后者是否可行。

为防止永久会话劫持，要求用户定期重新验证他或她自己（例如，限制允许的会话生命周期或需要令牌/fob/dongle 之类的东西）并要求用户重新验证他或进入应用程序的敏感区域，例如密码更改和潜在危险的操作、模式或行为（例如删除数据、异常使用模式、批量操作等）。

很难在保护应用程序的同时保持其易用性。如果做得仔细，安全性可以以一种侵入性最小但仍然有效的方式实施——嗯，无论如何，对于大多数面向 Internet 的应用程序而言。

【讨论】：

【解决方案6】：

这是不可取的，但如果你要这样做，至少在你这样做之前加盐你的密码。如果他们确实设法获取了访问者的 cookie，这将阻止人们使用哈希破解器。

【讨论】：