Question

This is not a question specific about some javascript detail but I’m looking for validation that there are no obvious holes in the model that I’ve created. I decided to roll my own authentication routine (except for using a bcrypt to hash in the backend) which will work like this:

1. User (browser or phonegap created native app) signs up > Json object posted using jQuery ajax to backend that uses bcrypt to handle the password and save the password user profile data
2. Backend generates, saves with client IP address a token which it returns (random hash, like /dev/urandom)
3. jQuery plugin stores the token to a local cookie
4. When some request is made (post, comment, whatever but not too often) it gets the token from the cookie and adds that to the json and posts it again with ajax
5. Backend checks that the token exists and has not expired (valid for 7 days), checks that the ip-address is the same and if ok validates the request json data and processes the request
6. When a token has expired a login screen is shown and credentials posted as ajax and a new token created as in step 2.

Everything goes through ssl for ajax requests and no passwords are stored anywhere. There is also a mechanism checking for brute force token spamming blocking the source ip temporarily if threshold exceeded. This is not a high security app but want to respect users data and make sure it’s secure “enough”.

I hope the question qualifies even though it’s not specific and work as a reference for someone else if it will spark some discussion. I couldn’t find any best practice tutorials on this particular approach.

UPDATE: The authentication mechanism updated according to the feedback received as it seems to be ‘secure enough’ for a non-critical web application.

Answer 1

I have tried to cover everything that I could think of from a high level perspective, given that you said your application isn’t a high security app, and you want the basic security controls in place.

The authentication flow, and the mechanism that it is using seems fine to me. The only point of concern I see here is the session management itself. Generating a session token using MD5 is fine (depending on whether you are using the correct pseudo random functions, which are seeded the correct way), though SHA1/SHA256 might be better choices if anyone ever tries to create a collision for your tokens.

I see a few things missing here – they might be omitted, or they might not be there, so I will mention them all. The first thing – you have not mentioned whether you ensure that there is a match between the user, and the cookie that you received. You need to make sure those two match, so that one user cannot steal a second user’s session.

The second thing I see missing here is validation that the cookie is NOT stolen from the user that it was from. For example, if I managed to steal the session cookie from a user, and replayed it on my own computer from a different place, I would still be able to login, with the current session handling mechanism.

You need a way to uniquely identify which computer the request is coming from – one way to do it (and the way that a PHP framework called CodeIgniter does it) is by verifying the IP address, as well as the User Agent that the request is coming from. The latter is easy to spoof, but the former is much harder. This makes your session more resilient to attacks – unless the application is used in a internet cafe on a public machine, and the user has not logged off.

That brings me to my final point – I don’t see a log out mechanism mentioned here, and how the log out is performed. The basic assumption would be that you would invalidate the session cookie as soon as the user logs out, and you don’t accept that session cookie again. If you haven’t done this already, that is something else you can do to ensure your session’s security.