https 上的明文密码存储在客户端时是否仍然安全？答案

【问题标题】：Does plainText password over https remains secure when stored in the client.?https 上的明文密码存储在客户端时是否仍然安全？
【发布时间】：2012-07-20 23:57:41
【问题描述】：

使用属性（httpOnly and secure=true）在服务器上设置 Cookiee 时，这是否意味着它只会在服务器和客户端之间的通信期间受到保护，而不是在那之后？换句话说，如果该值最初是在 plainText 中 - 它是否也会与 plainText 一起存储在客户端（在使用 https 之后） - 使其不安全/易受攻击？

1) 密码是否需要在发送前始终加密（即使使用 https）？

2) httpCookiee (withsecure=true) 存储在哪里？这种存储访问是否受到保护？

【问题讨论】：

人们总是可以使用 Firebug/Chrome Dev 来查看 cookie。 Tools/document.cookie 和 no cookie 未加密，因此请改用 SID 之类的东西。 HTTPS 实现 SSL(/TLS?) 所以被 RSA 加密
而且您不需要总是加密密码，只有当您想保护客户的安全

标签： cookies https password-encryption cookiestore

【解决方案1】：

您可能不想存储密码。

您需要存储一些“用户已通过身份验证”标志。

毕竟，您应该了解“摘要访问身份验证”。存储散列数据总是加分项。

这个答案太短了，主要是因为这里有太多的可能性 - 以及太多的开放性问题。

处理回头客：

您可以管理（服务器端）会话数据库。在您只存储会话 ID 的 cookie 中。当用户进行身份验证时，您将其状态存储到服务器端数据库中：“登录”。当他注销时，您更改数据库状态：“注销”。

以任何方式处理返回用户与“存储密码”无关。例如，您可以通过外部身份验证服务（如 open-id、twitter、facebook 等）对用户进行身份验证，您只是通过一些 session-ID 或类似的方式存储他的状态。

浏览器通常可以存储用户名/密码，但这始终应该由用户负责。当用户只想记住他的密码时，您不应以任何方式存储它。

为什么您希望通过在 cookie 中存储加密密码来使您的应用程序和安全机制复杂化 - 从任何角度来看，这不是正确的解决方案？

简单流程：

当新用户访问您的站点时 - 您为他分配一个新的会话 ID 并将 SID 存储到 cookie 中
当他登录时（通过 https） - 你存储在你的 DB = "sessionID" -> "logged in"
当他一周后返回时，您可以（服务器端）从 cookie 中接受他的会话 ID - 并且从数据库中您可以获得他的“登录”状态，或者，您可以再次强制登录他（例如因为过期）
以上所有内容都不存在以任何方式存储密码的风险

【讨论】：

感谢您的回复。实际上，我希望在用户返回我的网站时使用该 cookie（因此他不需要登录）。在发送之前使用散列而不是加密它会更好吗（例如，使用 rijndaelmanaged 类）？
所以，在我的印象中，它甚至不必是 sid ，它甚至可以是 GUID 或其他任何东西（真实密码除外）并且只要 cookie 没有过期用户可以登录
所以，在我的印象中，它甚至不必是 SID，它甚至可以是 GUID 或其他任何东西（真实密码除外）并且只要 cookie 没有过期用户可以自动登录。（它更像是服务器为特定使用时间和特定计算机启动的替代密码）正确吗？
正确。我主要使用 perl 和 Plack::Middleware::Session。它处理从生成唯一会话 ID、设置/获取 cookie、保持会话状态和将数据存储在缓存中的所有内容。所以我并不真正关心它的实施。我只需要 if( !$session->{loggedin} ) { do_login(); } 您的里程可能会有所不同。

【解决方案2】：

1) 我想是的。因为即使带有安全标志，cookie 也会以纯文本形式存储在浏览器缓存中

2) 这取决于浏览器和操作系统。对于 Mac 中的 Safari，您可以在 ~/Library/Cookies/Cookies.plist 中找到它。您可以看到带有 Secure 标志但以纯文本形式显示的 cookie。它可能受到保护，因此只有所有者才能看到，但在您的计算机中的任何地方都有纯密码永远不是一个好主意

【讨论】：

谢谢，我明白除了“...它可能受到保护，因此只有所有者可以看到...”部分之外的所有内容。它是如何保护的？
我的意思是cookie目录基本上不能被计算机的任何其他用户查看。更具体地说，用户 A 和用户 B 共享一台电脑，并且每个用户都有不同的登录用户，那么用户 A 看不到用户 B 的 cookie 目录。但是如果电脑被盗或被黑客入侵或发生任何事情，密码以纯文本形式存储，很容易被泄露。

【解决方案3】：

一旦安全标志设置为 true，即使在浏览器关闭后，cookie 也会加密存储在客户端中。正如你所说，这是不安全/易受攻击的。

分别。 1) 密码可以在使用 Javascript 发送之前进行加密，但这没有多大意义，因为 https 正在为您进行加密。

分别。 2) cookie 存储在浏览器文件夹中。任何人都可以使用文本编辑器打开文件夹并查看 cookie。

浏览器将为您处理密码。只需使用并使用 SSL 就足够安全了。并且，不惜一切代价避免将密码存储在 cookie 中。

【讨论】：

为什么将加密密码存储在 cookie 中如此困难？
cookie 很容易被欺骗。任何人都可以通过数据包嗅探器获取它，因为每个请求都会向服务器发送 cookie。
或者，如果黑客可以访问客户端计算机，他可以使用文本编辑器打开 cookie。获得 cookie 后，通过字典攻击、暴力破解或破坏加密算法来解密它只是时间问题。如果是 SHA128 或 MD5，则不应超过 2 个月。