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.
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.
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.
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.
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.
Related
I am developing single page application that would require sensitive data user password and private key. However, I would not want them to key in a password each time when it is needed.
What is the safest way to store this during login, without compromising security? I do not want to store it in localStorage, neither sessionStorage which are unsafe.
If you want to access this information inside your JavaScript code - then there is no secure way for that, the hacker can simply put a breakpoint in your code and inspect the relevant variables.
If you only need this info in order to maintain a "session" with the server - then you can use an encrypted session cookie, marked as HttpOnly and SameDomain. The cookie is called "session" because it automatically expires and disappears as soon as you close the browser. And it is encrypted (using a symmetric encryption like AES-256) so that only the server can decrypt it.
The cookie itself does not need to contain the password - it is enough to contain these 4 pieces of information:
user ID
IP address of the browser (to prevent using the same cookie from different locations)
timestamp of the last change of user data in DB (to invalidate the cookie as soon as the user changes his/her password or other sensitive data in their profile)
timestamp when the data inside the cookie should expire (to prevent using too old cookies)
Usually the data in the cookie should be considered expired after 20-30 minutes but you may choose to allow the user to set this time as a preference (with a maximum of 60 minutes).
And this cookie should be updated/refreshed with new expiration every time your SPA makes an AJAX request to your backend API.
I'm completing an unfinished project someone else worked on and trying work out how to create a secure page for an API driven front-end.
When a user logs in successfully, a local storage variable is being created that contains user information, including user token and user secret.
I require a secure dashboard page that calls secure API's.
Am I correct in the following approach :
When secure page loads, a JS routine is executed which checks local storage for user token. Can this be a simple check for user token existence ?
If token present then the secure API's are called using the secret key. The api then returns sensitive data to populate table.
Will this work?
UPDATE:
Both server and client will run under https. As data in encrypted, secret token can be stored on client. Front-End is static html/JS making API calls for sensitive data using secret (only available to authenticated user). None of the user data is hardcoded to F/E but instead is referenced from local storage. Then tokens can be used securely to make further API calls as required for sensitive data. So basically, no-one else should be able to get to sensitive data as cookie/storage is limited to client machine and will expire anyway.
I was looking for a blog/tutorial to confirm my understanding as above.
Thanks
This approach seems OK. I don't know your exact requirements, but I would suggest using a cookie instead of localstorage, given that the token is sensitive information and should not be stored for a long time if it doesn't have to.
If the user has it's personal permanent access token go with localstorage. If the token is fetched from an auth-server upon login, use cookies instead.
I have a website which clients can log in to. Their username, encrypted password and some additional info is stored in an SQL database on the server. I am setting up a cookie to remenber the user for some days.
I read everywhere I should not save the username and password in the cookie for security reasons. I have to say I am not sure to see why. The cookie is stored on client side right? Thus it is his username and password he is able to see, what is unsafe in that?
Anyway I pretty sure there are good reasons and it is just I cannot see it, I read the solution is to do that:
hash and encrypt the password
store the login information to a file on the server
give the file a unique name
store the name to a cookie
each time you receive the cookie with the correct file name, look up the file and retrieve the login information.
So I should generate a unique ID to store in my database and associate it with the user.
How can I achieve that?
You don't need to store the username and the password. You could instead store a session key (saved in database) with an expiration date.
If you store username and password locally that is not a huge problem if the user is at home, but what if the user is not at home ? What if the user is not on his own computer ?
Even encrypted, some "bad guys" could get it.
The problem is that the user can change the cookie value. So he can set the username to someone else's name.
Instead of putting the username in the cookie, put the unique filename in the cookie. This is essentially how PHP sessions work -- they put all the session data in a file, and set a PHPSESSID cookie with the name of the file.
should not save the username and password in the cookie...not sure to see why
Because the user may not be in exclusive control of the client - e.g. a public access terminal, or even with a personal computer, this extends the attack surface for malware. The longer lifetime of the entity compared with a session identifier increases the attack surface too.
And if it's not properly encrypted and re-validated then the user can easily change the data to that of someone else.
As to the remainder....
give the file a unique name
File? What file? You are trying to implement a surrogate authentication token. The specifics of how you do that depend on the programming language and the policy you want to implement. Should the system allow for the user to store tokens on multiple machines (which implies multiple concurrent values)? Should it be strongly tied to the machine it was initially assigned to (in which case how do you establish the identity? Using the IP address or user agent has limitations)?
Generally you should store the mapping between the token and the account (and additional meta data such as machine identity and expiry) on the server.
I have a single-page AngularJS app, and authenticate my website via websockets using no cookies. This means a refresh logs the user out. How bad is it to store the password on sessionStorage, so they can refresh during the session? (The username will be in localStorage, and I don't want the full login to persist between sessions).
Thanks!
EDIT:
What I'm more interested in is if there are there any actual security risks for storing in such a way. Is it any less secure than how Chrome stores passwords in plaintext, or how cookies are unencrypted?
Are you trying to avoid localstorage, or just cookies?
You could store a session ID in the session storage, and authenticate the user using that, under no circumstances would I store a users password cleartext though.
I don't think you'd want to store the password. You could generate a session token and store that in the sessionStorage. Anyway, if you come to store the password itself, don't store it as plain text.
What you want to do is... create some hash on your server, and save it on the localStorage.
Send this hash on each request, and the server should validate/handle it, and respond with the appropriate credentials.
But that is also 'not as secure as you may want it to be', so... you can change the hash every x minutes, or have it time out after X minutes of innactivity.
Never store plain text passwords, and never include your hashing algorithm on the client side.
I have: websocket secure connection (wss) through the whole app. + Backbone.js on client side if it's significant.
I want: automatically log in user on new tab opening, if he's already logged in another tab.
Question: what is better either use cookies or localStorage?
If you use localStorage, the user's credentials will be stored (presumable unencrypted unless you implement this yourself) on the user's local machine. These records will not expire unless you write your application to do this. As such your user would be logged in forever, not just if they have another tab open, unless you also wrote logic for that. But there is no reason to do all this additional work.
Cookies are already frequently used to accomplish this functionality. Inside the cookie you should store a session token, which identifies the user's session uniquely. Cookies have the advantage of automatic expiration, and are automatically passed to the server with each HTTP request. For more information about the differences between cookies and localStorage, take a look at this thread.