dimanche 29 mars 2015

Security when using HTML5 localStorage to store "session" tokens

i'm building a stateless authentication and authorisation system for a Dart frontend and just want to get feedback if this is a secure way of doing it.


I have a login page which asks for a username/email and password.


enter image description here


Upon entering a correct username / password combination, you are sent back a session token (which is a bunch of UUIDs concatenated together), a hash which is a SHA1 of the username + some random salt and a timestamp. The backend stores the hash, username and session token in a Redis database and updates the timestamp to the current date-time.


The username, session token, hash and timestamp is then stored in HTML5 local storage in the frontend.



window.localStorage["session"] = response["session"];
window.localStorage["username"] = request["username"];
window.localStorage["timestamp"] = response["timestamp"];
window.localStorage["hash"] = response["hash"];


enter image description here


Each request coming from the frontend needs to include all 4 these fields. The session token, username and hash is then validated against the Redis database. If the session, username and hash matches, the timestamp is checked to make sure that the difference between the last request's timestamp is not bigger than 30 minutes.


If everything succeeds, the timestamp is updated in the Redis database. If anything goes wrong or doesn't match, the whole "session" is removed from Redis. There's a cleanup job that kills sessions older than 30 minutes.


Data is only sent back to the frontend if authentication succeeds, if the session token is invalid, no data is sent back and the existing session for the username is killed.


So unless i missed something, unless you know the username, can guess the session token first shot, guess the hash first shot and guess a timestamp that's within 30 minutes of the last request, your request for data will be denied and all further requests will be denied due to the session getting invalidated.


The other option is hijacking these tokens (either via man-in-the-middle if it's not going via SSL or somehow accessing it directly in the local storage), what is the possibility of this happening and what would be a workaround to prevent this?


Aucun commentaire:

Enregistrer un commentaire