Storing Credentials in Local Storage

问题:

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.

回答1:

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.

回答2:

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.

回答3:

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.

回答4:

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.