在网站访问之间安全存储凭据
我正在建立一个网站，允许用户创建帐户并访问网站的内容。 我不希望用户每次访问该网站时都登录，因此我计划将用户名和密码存储在 cookie 中 - 但是，我听说这是不好的做法，即使密码经过哈希处理饼干。
我应该遵循哪些“最佳实践”才能在用户访问我的网站期间安全地记住用户凭据？
I'm building a website which allows users to create accounts and access the site's content. I don't want users to log in each time they visit the site, so I'm planning on storing the username and password in a cookie -- however, I've heard this is bad practice, even if the password is hashed in the cookie.
What "best practices" should I follow to safely remember of a users credentials between visits to my website?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
永远不要这样做。 公开传递密码。
最安全的方法：
将用户名存储在数据库中，在同一行中存储随机生成的盐值，在同一行中存储包含盐的密码的哈希校验和。 将另一个表用于引用带有用户凭据的表的会话。 当用户登录时，您可以在会话表中插入您希望会话过期的日期（例如 15 天后）。 将会话 ID 存储在 cookie 中。
下次用户登录时，您将获取密码，为用户添加盐，获取哈希值，将其与您拥有的密码进行比较。 如果它们匹配，则通过在会话表中插入一行并在 cookie 中发送会话 ID 来打开会话。 您可以通过此cookie检查用户是否已登录以及是哪个用户。
编辑：
此方法在大多数网站上最流行。 它在安全性和实用性之间取得了很好的平衡。
您不只是对会话 ID 使用自动增量值。 您可以通过使用一些难以重复的复杂校验和来实现。 例如，连接用户名、时间戳、盐、另一个随机盐，并从中生成 md5 或 sha 校验和。
为了实现涉及网站/服务中的用户凭证的功能，大多数情况下在客户端和服务器之间需要交换一些与凭证相关的数据。 这会将数据暴露给中间人攻击等。此外，cookie 还存储在用户的硬盘中。 没有一种方法是 100% 安全的。
如果您想要额外的安全性，您可以让您的网站通过 https。 这将防止人们使用中间人攻击窃取 cookie 和密码。
注意：
混合使用 IP 地址并不是一个好主意。 大多数情况下，多个客户端会通过 NAT 等来自同一 IP 地址。
Don't ever do that. Throwing around passwords in the open.
Safest method:
Store the username in a database, in the same row a randomly generated salt value, in the same row a hash checksum of the password including the salt. Use another table for sessions that references the table with user credentials. You can insert in the sessions table when the user logs in a date you want the session to expire (eg. after 15 days). Store the session id in a cookie.
Next time the user logs in, you get the password, add to it the salt for the user, geterate the hash, compare it to the one you have. If they match open a session by inserting a row in the sessions table and sending the session id in a cookie. You can check if the user has logged in and which user it is by this cookie.
Edit:
This method is the most popular in use on most sites. It hits a good balance between being secure and practical.
You don't simply use an autoincrement value for the session id. You make it by using some complicated checksum which is hard to repeat. For example concatenate username, timestamp, salt, another random salt, and make an md5 or sha checksum out of it.
In order to implement a feature that involves user credentials in a website/service there most be some exchange of data related to the credentials between the client and the server. This exposes the data to man in the middle attacs etc. Additionally cookies are stored in the users harddrive. No method can be 100% safe.
If you want additional security you can make your site go over https. This will prevent people from stealing cookies and passwords using man in the middle attacks.
Note:
Involving IP addresses in the mix is not a really good idea. Most often multiple clients will come from the same IP address over NATs etc.
您不需要存储密码，只需存储您的应用程序可以解释为用户的标识符。
您需要注意的事项：
处理这些问题的可能解决方案是为每个用户创建一个一次性密钥，当他们下次使用该应用程序时该密钥会被更改。
您可能永远无法完全安全地记住用户，因此仅应在不涉及敏感数据的情况下使用此功能。
You shouldn't need to store the password, just an identifier for the user that your application can interpret to be them.
Things you need to be aware of:
A possible solution to deal with these would be to create a one-time key for each user that is changed when they next use the application.
You will probably never be able to remember a user fully securely, so this should only be used if there is no sensitive data involved.
任何形式的密码都不应该存储在 cookie 中。 Cookie 很容易被盗。
一些浏览器已经支持保存密码。 为什么不让用户使用它呢？
Passwords in any form shouldn't be stored in cookies. Cookies can easily be stolen.
Some browsers already support saving passwords. Why not let the user use that instead?
将用户名的哈希值存储在 cookie 中可以提供“记住我”的功能。
然而，对于系统的敏感区域，您需要知道用户是通过缓存的凭据进入系统的，以便您可以在让他们造成任何真正的损害之前提供用户名/密码提示。 这可以作为基于会话的标志来保存。
Storing a hash of the username in a cookie could provide this "remember me" functionality.
However for sensitive areas of the system you would need to know that a user entered the system on cached credentials so that you could offer a username/password prompt before you let them cause any real damage. This could be held as a session based flag.