将凭证存储在本地存储中
我可以安全地使用本地存储而不是 cookie 来存储会话凭据吗？
我需要存储加密的哈希值吗？
编辑：这足够安全吗？
用户登录。
服务器返回成功消息，包括加盐 bcrypt 哈希混合用户 ID、密码、时间戳，可能还包括 IP 地址。这保存在本地存储中。
在将来的连接中，将发送此哈希值，只要 IP 地址未更改且时间限制未过期，服务器就会承担责任。
Could I securely use local storage instead of cookies to store session credentials?
Would I need to store an encrypted hash??
EDIT: Would this be secure enough?
User logs in.
Server returns success message including salted bcrypt hash mixing userid, password, timestamp, and possibly ip address. This is saved in local storage.
On future connects this hash is sent, server assumes accountability as long as IP address hasn't changed, and time limit hasn't expired.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
localstorage 与 cookie 一样容易被 JavaScript 读取。
localstorage 可以使用 JavaScript 从相同域读取，如果您控制域上的所有 JS，那么这应该不是问题。但是，如果执行任何其他代码（例如通过注入，或者与其他人共享域），他们将能够访问存储数据。
然而，这对于 cookie 来说是相同的，但通常 cookie 设置为 HTTPOnly，因此 JavaScript 无法读取它。
无论哪种情况，纯文本登录信息都不应该存储在 cookie 或本地存储中，就好像有人确实掌握了它们一样，他们可以不断地为自己创建新会话。
您应该对经过身份验证的标识符（例如用户 ID）以及会话到期的日期时间进行加密，然后将该值存储在 cookie 或本地存储中。然后在每次服务器调用时验证该令牌。
localstorage is just as vulnerable to being read by JavaScript as cookies are.
localstorage can be read using JavaScript from the same domain, if you control all the JS on the domain, then this shouldn't be a problem. But if any other code is executed (via injection for example, or if you share the domain with someone else), they will be able to access the storage data.
This is the same for cookies however, but typically the cookie is set to HTTPOnly so JavaScript cannot read it.
In either case, plain-text login information shouldn't be stored in either cookies or localstorage anyhow, as if someone does get hold of them, they can continuously make a new session for themselves.
You should encrypt an authenticated identifier (such as their user ID) along with the datetime of the session expiration, and then store this value in either a cookie or local storage. This token is then validated on each server call.
如果您要使用本地存储，为什么要存储用户凭据或从它们派生的任何内容？
我一直在考虑做的是：
成功登录后，生成一个与用户凭据无关的完全随机的字符串，并将其连同到期日期一起存储在数据库中。然后我会将该字符串传递给我的 js 以存储在本地存储中。
从那时起，只要本地存储凭证与数据库凭证匹配并且超时尚未到期，我就会自动认为他们已登录。
这样，就不存在本地存储中暴露用户凭证的风险。然而，由于这个临时的唯一字符串本质上起到了会话 ID 的作用，您仍然需要了解并采取预防措施来防范与会话劫持相关的风险。
无论如何，我的理解是本地存储与站点背后的服务器一样安全。我的意思是，本地存储只能通过您自己的域中的脚本进行访问，因此只要运行的唯一前端代码是您自己的，您就是安全的。
If you're going to be using local storage, why store user credentials or anything derived from them at all?
What I've been looking into doing is:
Upon successful login, generate a completely random string unrelated to user credentials and store that in the database, along with an expiry date. I would then pass that string to my js to be stored in local storage.
From then on, so long as that local storage credential matches the database one and the timeout has not expired, I automatically consider them logged in.
This way, there is no risk concerning the exposure of the user's credentials from local storage. However, with this temporary unique string essentially functioning as a sessionID, you will still to need to be aware of and take precautions against the risks associated with session hijacking.
In any case, my understanding is that local storage is as secure as the server behind your site is. By that I mean local storage is only accessible via scripts coming in through your own domain, so you're safe so long as the only front code running is your own.
您的服务器应生成一些令牌 - 无法用于发现用户名/密码的唯一（对于服务器）数据。只有该令牌才能以任何形式存储在用户的计算机上。 localStorage 和 cookie 都不安全。因此，在这方面，同样的规则也适用于他们。
您应该有一些方法来使此类令牌过期，否则一旦被盗，可以使用此类令牌来代替真实的凭据。
You server shall generate some token - unique (for the server) piece of data that cannot be used to discover username/password. Only that token can be stored on user's machine in any form. Neither localStorage nor cookie are secure. So the same rules applied to them in this respect.
You should have some means to expire such token otherwise once stolen such token can be used instead of real credentials.
如果您打算使用 localStorage 而不是 cookie，您可以使事情比 cookie 更安全。这是因为您不需要在每个请求中将会话 ID 发送到服务器，使其成为不记名令牌。相反，您可以在客户端的 localStorage 中存储用户密钥，除了发送相应的公钥并用作会话 ID 之外，还可以用它来签署您的请求。这样，服务器端或代理上的任何人都无法伪造您的请求。
If you're going to use localStorage instead of cookies, you can make things more secure than cookies. That's because you don't need to send a session id to the server with each request, making it a bearer token. Instead, you can store a user secret on the client side in localStorage, and use it to sign your requests in addition to the corresponding public key being sent down and used as the session id. This way, no one on the server side or proxy can fake your requests.