Analyze my custom web authentication scheme, based on a token derived from username and password

Question

To avoid having the user to login every time his session expires, I want to implement a token based authentication system.

My scheme works like this:

1. Send the user login (send name + password) via $.ajax() to a https URI
2. Create a token via $token = bin2hex(openssl_random_pseudo_bytes(16));
3. Save $token, userid and date in a database (only accessible by SSL)
4. Echo the $token and userid to the client
5. Save the $token and userid in html localStorage on the client
6. When doing an $.ajax() from client always send userid and $token as POST
7. Serverside, match the provided $token and see if it is still valid (date not expired).
8. If it's alright, continue to deliver the requested material

Can you analyze my scheme?

Many people advise against implementing custom authentication processes, as they are often vulnerable to attacks. This makes me suspect that my approach may also have flaws. Can you reveal these flaws to me?

Answer 1

So there are a few reasons why you don't want to do this, although I do not understand the code you presented as I do not deal with that. You should use a third party library to manage your sessions. There are several reasons...

1. Code is vetted, tested and improved across a much wider audience when you use a built in or well know authentication scheme.
2. When and if you leave, someone is not stuck dealing with a custom created authentication mechanism
3. There are probably vulnerabilities in the code, it may or may not be directly in your code but in a service you call, updating that single service may cause issues through the rest of the code, such as deprecated arguments and variables. This may not make your program less secure but it may break it.
4. Self support is tough, especially when you do a good job and it is running without issue for a year or two, then bam!! in the middle of another project something breaks and you have to take the time to troubleshoot it from the bottom up.
5. CYA, if you make a mistake and something bad happens, you are the one people will come back to and ask, why didn't you use this or that scheme that is not vulnerable to some attack and you will have to explain that.

Anyway, I hope that helps

Answer 2

On the face of it, with a MITM I can just get access to your webapp as long as one your users is using my "wifi"

Also, why use something unproven when you can use proven technology (OAuth2 would suffice for your purposes and that has been security-tested)

And you have no checking built for brute-forcing your "token" meaning I can just brute-force as soon as I get a "userid" (probably a number so easily guessable).

Also, this example lacks protection against SQL-injections, meaning I could just give mysql a valid token and login to anyone's account.

Solving all of them (without creating hidden backdoors / etc) is nigh impossible for one man. Just use one of the libraries available from the open source community, one that is tested and verified!

Answer 3

Not a bad start. Some things to watch for:

• If login fails, don't reveal whether the user exists
• Implement some form of brute force protection
• Provide a change password function; require the previous password
• Perform password strength checking
• Sessions usually have both inactivity and absolute timeouts
• Store passwords securely, e.g. bcrypt
• Use an anti-CSRF token
• Let users self-manage sessions

And that's just authentication and session management. There's a whole load of other security considerations: SQL injection, cross-site scripting, use of SSL/TLS, etc.

Most authentication libraries do NOT solve all these problems in the default configuration.

Answer 4

If you take the standard session-id pattern, and implement it using a persistent cookie rather than the more typical session cookie, you get exactly what you describe, only you get a professional implementation of it done by the browser.

Remember: not only can your algorithm have flaws, but your implementation can have flaws as well. The more you have to implement, the higher your risk. Lawri pointed out that you are now responsible for making sure there are no SQL injection attacks in your system.

If you really want to do this yourself, the proper way to vet the algorithm is to identify how someone can use the information. As you have it written, the only difference between your token and a password is that the token technically expires (server side). Accordingly, you should write your code treating tokens with exactly the same care and attention you would give to storing and transmitting a password.

At an absolute bare-bones minimum, you must implement SSL to protect from Firesheep style sniffing attacks as Lawri mentioned. If you don't, then you probably should not be implementing your own session-id systems when this is generally recognized as a "solved problem."