I don't understand what's wrong with just using cookies for authentication?

Question

I'm writing an app-server and there is an option to just use secure cookies for authentication. Here's how it seems to work:

1. You define a 32-byte secret key on the server
2. When the user logs in, you check the database to see if the bcrypt hashes match, and if so, you call request.remember(user_id)
3. On route handlers that require authentication (and the user_id), you unwrap the user_id by decrypting the cookie and if it's valid, you continue. Otherwise, return an Unauthorized error.
4. If a user hits the logout handler I just call request.forget() and the cookie is deleted on the client.

This all seems to work. So what I'm curious about is why doesn't everyone just do this? I look around and there seems to be a lot of talk of JWTs, generating auth token UUIDs and storing them in Redis/the database, etc. So apparently this method isn't secure? And you need to store state on the server?

If I were to guess, I'd say a problem with this approach might be that if the cookie is stolen somehow (not sure how since it's all over TLS and the cookies are HTTP-Only and Secure if that matters), then the user would be able to be impersonated by an attacker. But I think this would apply to the other schemes too?

Another issue I could see is that a user could just randomly generate auth tokens until they found one that matched a user? But I'm not sure if this is a problem either since I'd just rate limit the authentication handler and I'd imagine this sort of thing would take a while? Oh, maybe they could make 100 accounts and see what the encrypted cookie auth token looked like and bruteforce it client-side to find out what the secret key on the server was? And then they'd be able to impersonate users by generating auth tokens? Although I think it would take way too long to find the key since it's 32 bytes?

I guess this approach doesn't automatically expire cookies (is that why this isn't used much? But I think there's a way to add an expiry header to cookies? Would that work?) I'm not even sure if I need expiration for this app.. Seems like it would annoy users. How long do sessions last at places like Google/Facebook? I feel like I'm always logged into those services forever.

I don't know. I feel like I'm missing a lot of information here. Is there somewhere where I can find a pros and cons list of all these different approaches?

Answer 1

The scheme you describe is potentially vulnerable to cross site request forgery (CSRF).

An malicious request could be made on behalf of the user. This request would send the cookie which would pass the authentication checks, and perform any activity the user could themselves.

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)

If you look at the link above to the OWASP article on CSRF it specifically lists secret cookies as an invalid mitigation technique.

Answer 2

Assuming you are using your cookies as a stateless authentication identifier then your scheme is basically similar to JWT except created with cookies. The main differences are:

1. JWTs are generally only signed instead of encrypted (though you can encrypt them as well). What this means is that you can ask third party services to create tokens for you. This allows you to plug your application into other authentication services or provide an authentication service yourself for other apps.
2. Mobile native apps and cookies might create problems. Generally can be overcome but the implementation can be a lot trickier than using tokens which only need to be attached as text to a request header or body and are easily stored.
3. JWTs are easier to work with especially in javascript environments as you can pretty much attach any metadata you want to the claims and can read them as you would normal JSON. It also helps that with their popularity you can find ready-built solutions for more of the modern frameworks.
4. Cookies are vulnerable to cross-site request forgery (CSRF) while tokens will depend on how you store them (cross-site scripting (XSS) if in web storage, CSRF if you decide on storage cookie).

In summary what you are suggesting is solid, but it's basically the same as JWT missing a few of the benefits. If your system has no need for third party integration then by all means go with cookies, but make sure to secure them against CSRF as mentioned by @Daisetsu.

Answer 3

You're mostly right. The cookie is encrypted, so the contents cannot be seen or messed with. (Unless the encryption is broken.) The cookie is sent only over TLS, so it can't be stolen by a MITM. (Unless your cert is compromised somehow.) The cookie is set to HTTP-Only, so it can't be stolen by any malicious JS. From all of the angles that make sense, it's safe.

I have but one gripe with your setup. You're using a persistent identifier for the user in that cookie. In the unlikely event that something does go wrong, the compromise will last the lifetime of your user record. Generate some random string, store that someplace, and use it to reference your user. That way, you're constantly recycling what would ID a user, containing any breach to the session lifetime.

Consider also opening up popular frameworks and studying how they handle this. You may pick up some useful techniques to make things even safer or more efficient.

As for JWTs and such, there's a blend of them being the new shiny that people want to use and them being a genuinely useful technique for having authentication exist on a separate system than where the user needs to be authenticated.

Edit: Did a little diving into Laravel to see how they do it. They just store the user ID into session. Session is server-side and therefore safe. This separates it from session handling, which seems proper. The session identifier is a random 40 character string. That gets set as HTTP-Only.