What's wrong with my own authentication scheme?

Question

So I want to write my own authentication scheme for a web-app server, as follows. I assume this is a Bad Idea from either security or cost-effectiveness reasons and I know the conventional wisdom is using an existing library, but I'd be happy for pointers as to where exactly I would be going wrong, since this scheme seems both secure and easy to build.

In Pseudo-API, I would respond to the following:

1. POST /login,signup (+username, passwd) -> create and return token for this user. (Save user<->token relationship on server.)

2. POST /logout (+token) -> destroy token for this user on server. (Destroy user<->nothing relationship on server.)

3. POST /any-action (+token) -> perform action if token is correct. (user and token match user<->token on server.)

Is the above an insecure paradigm?

Answer 1

Yes, this is insecure as specified.

Your design seems to be vulnerable to Cross-Site Request Forgery (CSRF also known as XSRF) attacks (need to add a CSRF token with all POST actions that is displayed with the form and stored in a session cookie). Basically, if a user goes to some other website (email, forum, blog) while logged into your website, their browser may be forced (by javascript, by a secret form) to make an unintended POST request to your website doing some action that I don't want.

Your scheme also isn't particularly specific.

• How are passwords dealt with (bcrypt or PBKDF)? Or at the very least a salted hash? Are they checked with a constant time string comparison right?
• How is data protected over the network during transit (HTTPS?),
• How is data inserted/pulled from the database? Prepared statements (also known as parameterized queries) everywhere? (Great!) Or do you execute a string with an SQL command containing user input (Vulnerable!)?
• How are tokens are stored in the browser (Secure HTTP-only cookies?)

Quite possibly they could be other flaws in the implementation as well.

Answer 2

What you present is not an authentication protocol; it is merely a concept, namely the concept of a session token.

In plain words:

• Server authenticates client, and send back a secret key to that client (the session token).
• When the client comes back, it shows the token to the server to prove that it is the same client as previously.
• The client can request the server to forget the token (of course, and contrary to what you show, that "logout" request too should include the token, otherwise anybody could logout everybody else).

There is nothing wrong in this concept, as long as you understand its limitations. For instance, it inherently relies on the client/server communications to be both confidential (so that no passive attacker eavesdrop on the token) and resilient to tampering (so that no active attacker may hijack the connection just after the authentication). In short words, SSL (i.e. HTTPS) is mandatory.

I agree with you: this scheme seems easy to build. But take care: it is an illusion. In fact, it is not easy at all to build a secure authenticated session system, even if the concept is clear and simple. Building a system which works is easy, and can be tested; security, though, cannot be tested and is a lot more work than usually assumed.

There is a stupendously high number of ways the realization may derail. @jimbob gives you a few (and the list is not exhaustive at all). The art of computer security is not about making system works properly under normal conditions; it is more about making sure that systems do not work too improperly under abnormal conditions.

Answer 3

The funny thing about providing a generic 'gist' of an authentication flow is that unless you really screw up the flow, you likely won't find serious issues because there just isn't enough detail to say one way or another. More often than not, its the implementation that is flawed.

This is further complicated by the fact that you don't specify what you're protecting against. Passing just a username and being logged in is perfectly secure* -- under the right conditions. The question you need to ask yourself is who or what you're trying to protect against, and whether or not your authentication flow has provided protective measures against whatever those bad guys will throw at you.

You mention passwords... how are you verifying the passwords?

Session Tokens... how are you generating them, how are you storing them on the server, how are you storing them client-side, how are you validating the token on 'any-action'?

More questions etc...

That is why it's recommended you don't build you own. Odds are pretty good you haven't thought about every angle, whereas developers of a well-known component might have. As an example, to say that generating a session token is 'just an implementation detail' is not totally incorrect, but its a serious detail that will screw you royally if you mess it up.

So my answer to your question is: yes, it's insecure because there isn't enough detail to say one way or another.

*Well maybe not, but you get the point.