'Remember Me' combined with Auth Token

Question

I've developed a client application which talks over a REST API to a server. The way the application works is to send the username/pwd pair in the initial login to the server and then respond with an auth token in the form of a newly generated GUID.

The client uses the GUID to talk to the server for the remainder of the session (forever until the local storage is cleared). The login page requires the ability to stay logged in. To achieve this, I store the GUID token in local storage. If the key is there then it auto-logs into the app.

All of the comms is carried out over SSL so I'm not worried about the security of the data or MITM, but I am concerned about the security of the token stored in local storage.

Some questions:

• Should I encrypt the GUID further? Does this give me anything?
• Is storing the GUID auth token in local storage a big security risk? Worth securing?
• Does storing the token inside a cookie improve matters at all?

I also thought about having the server generate new tokens every new login and reduce the window of attack, but that would then prevent the 'remember me' feature from working.

Answer 1

When you say GUID is that an actual GUID as per spec, or a proper randomly generated key? If its not random that's the biggest issue right there because your session security now relies on something very easily guessed.

Given that, to answer the other questions you need ask yourself: what are you protecting? what are you protecting against? What sort of attackers? How much effort are you and/or they willing to put into it?

Then you have to consider that what you're looking at is protecting a key on a client system that is potentially hostile. You could encrypt the session key, but with what key? What algorithm? Do all browsers support the necessary algorithms? How do you protect that key? Most browsers don't support crypto so that complicates things a whole lot.

Storing things in local storage is better/worse/equal to storing in a cookie. On the one hand its better because it can help protect against CSRF because to get access to the session key you need to execute within a context that can access local storage, whereas a cookie will pretty well just be sent to the server on every request so long as the cookie is valid. However, local storage was never really meant for storing sensitive things like session keys so it doesn't necessarily get the same level protection as a cookie store on a machine (history being what it is, cookies had the same issue back in the day too). Cookies nowadays also have protection against access from JavaScript, so XSS can't do funny things with sessions like ship the keys off to another server, whereas local storage is only accessed from JavaScript.

A potential mitigation is to use both a cookie and local storage to create a composite key of sorts, but there could be complications with that too.

You could also refresh the token every so often and make sure its invalidated on the server to prevent long-lived keys, but that doesn't necessarily solve anything if a user only visits every few weeks.

Clear as mud?