Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSON Web Tokens should be avoided

paragonie.com

Post reply on HN
Print view View original

261–270 of 304 posts

Re: JSON Web Tokens should be avoided

#261

Post by andy_ppp »

joepie91_ wrote: post #258
andy_ppp wrote: post #62

Earlier quoted context omitted.

Yes, this prevents CSRF without tokens too.

... and causes another security issue in the process, namely the ability to steal session credentials after an XSS attack. Trading in one security issue for another makes no sense. Just implement the correct mitigation against CSRF attacks; namely, CSRF tokens.

Yes but you can now concentrate make yourself XSS proof right; with an XSS you can still get someones cookies... unless you are talking HttpOnly. But we are probably talking single page webapps here anyway.

Re: JSON Web Tokens should be avoided

#262

Post by Alex3917 »

igl wrote: post #260
Alex3917 wrote: post #244

Earlier quoted context omitted.

> So every user on your system has to reauthenticate if one client token is compromised? No, because you would also store either a separate datetime or uuid on each user model. And if just one user has their credentials compromised, then you would bump the date or generate a new UUID for just that user. The global datetime would only be bumped if some site wide vulnerability were found.

So there is a db roundtrip involved? Like a inverted session. Whats the point of using jwt then?

For most web frameworks, the user model gets retrieved from the db automatically whenever an authenticated request is made. So there is no extra lookup.

Re: JSON Web Tokens should be avoided

#263

Post by tboyd47 »

tracker1 wrote: post #246
tboyd47 wrote: post #104

Earlier quoted context omitted.

The article very clearly is about the standard , not a particular JWT library. Server-side session tokens stored in the database worked fine ten years ago, and they work fine today. No need to muck with the load balancer. Stateless tokens are great too, and use two-factor auth when you need that extra layer of security. No need for newfangled standards; HTTP Basic remains a simple and effective way to convey that tok…

Except there are now many instances where no single database server can keep up with request load. It's not fine in all cases today. Where I work now a single request from the user goes into a pipeline of requests (some can be parallel, others not)... our SLA is X, everything that adds up to the total request time counts. Adding even 2-3ms for each service layer to verify session keys is too much. This is as opposed…

I've got nothing against stateless tokens. What I'm saying is that it can be a much easier and more effective pattern to add a second layer of security than to add complexity to the first layer (the token). I believe this is like the idea of defense in depth. For example, making signed-in users re-enter their password before performing certain actions may be preferable to introducing cryptography into all sign-in actions.

Re: JSON Web Tokens should be avoided

#264

Post by tofflos »

tracker1 wrote: post #246
tboyd47 wrote: post #104

Earlier quoted context omitted.

The article very clearly is about the standard , not a particular JWT library. Server-side session tokens stored in the database worked fine ten years ago, and they work fine today. No need to muck with the load balancer. Stateless tokens are great too, and use two-factor auth when you need that extra layer of security. No need for newfangled standards; HTTP Basic remains a simple and effective way to convey that tok…

Except there are now many instances where no single database server can keep up with request load. It's not fine in all cases today. Where I work now a single request from the user goes into a pipeline of requests (some can be parallel, others not)... our SLA is X, everything that adds up to the total request time counts. Adding even 2-3ms for each service layer to verify session keys is too much. This is as opposed…

If you're on Java and using an ORM like Hibernate, then that user will be found in the second-level cache. This will eliminate the need for a database roundtrip for all requests after the first authentication. From that point on that particular user will be retrieved from memory.

Re: JSON Web Tokens should be avoided

#265

Post by floatboth »

throwaway2016a wrote: post #134
floatboth wrote: post #30

Earlier quoted context omitted.

Yeah, and that's kinda sad because now you have to check a signature AND query a database!

Two solutions: 1. As other posters pointed out. The blacklist is probably pretty small and can live in memory on your apps servers. If you have a distributed raft network or something to keep it in sync across nodes, even better. 2. You can avoid checking it against the DB unless the API call is sensitive (example: modifies data).

Yeah, of course you can do these things. I really meant to say, "there now exists server-side state for this" — I'm bothered by how existence of that state defeats the statelessness benefits of signature-based schemes, not the fact that I have to query a remote database.

Oh, and also: "only store a blacklist" does not work if you want to provide the "revoke this app you gave access to a while ago and now it's spamming" functionality like in most social networks.

Re: JSON Web Tokens should be avoided

#266

Post by tracker1 »

tofflos wrote: post #264
tracker1 wrote: post #246

Earlier quoted context omitted.

Except there are now many instances where no single database server can keep up with request load. It's not fine in all cases today. Where I work now a single request from the user goes into a pipeline of requests (some can be parallel, others not)... our SLA is X, everything that adds up to the total request time counts. Adding even 2-3ms for each service layer to verify session keys is too much. This is as opposed…

If you're on Java and using an ORM like Hibernate, then that user will be found in the second-level cache. This will eliminate the need for a database roundtrip for all requests after the first authentication. From that point on that particular user will be retrieved from memory.

Which will require session pinning for the load balancer, not to mention, I'm not using Java or a similar ORM. That will only help for a single instance of an application on a single server... not much help when you specifically don't want session pinning.

Re: JSON Web Tokens should be avoided

#267

Post by tracker1 »

tboyd47 wrote: post #263
tracker1 wrote: post #246

Earlier quoted context omitted.

Except there are now many instances where no single database server can keep up with request load. It's not fine in all cases today. Where I work now a single request from the user goes into a pipeline of requests (some can be parallel, others not)... our SLA is X, everything that adds up to the total request time counts. Adding even 2-3ms for each service layer to verify session keys is too much. This is as opposed…

I've got nothing against stateless tokens. What I'm saying is that it can be a much easier and more effective pattern to add a second layer of security than to add complexity to the first layer (the token). I believe this is like the idea of defense in depth. For example, making signed-in users re-enter their password before performing certain actions may be preferable to introducing cryptography into all sign-in act…

This isn't just for all sign-in actions.. it's for all API requests, and in some designs passthrough requests on behalf of a user to another server/service. It isn't just used for UI requests. It can also be used from Server to Server/Service requests... across data centers. You can do signed tokens/authentications without introducing many potential points of failure.

Re: JSON Web Tokens should be avoided

#268

Post by [deleted] »

justinclift wrote: post #233
mwpmaybe wrote: post #150

Earlier quoted context omitted.

Probably not. If the Pg instance is replicated, as indicated above, it'll be challenging to keep the Memcached copy in sync. In other words, you can't just use the caching feature of your ORM, you'll need another piece.

Thanks, that does need further thinking about. :)

[deleted]

Re: JSON Web Tokens should be avoided

#269

Post by tofflos »

tracker1 wrote: post #266
tofflos wrote: post #264

Earlier quoted context omitted.

If you're on Java and using an ORM like Hibernate, then that user will be found in the second-level cache. This will eliminate the need for a database roundtrip for all requests after the first authentication. From that point on that particular user will be retrieved from memory.

Which will require session pinning for the load balancer, not to mention, I'm not using Java or a similar ORM. That will only help for a single instance of an application on a single server... not much help when you specifically don't want session pinning.

I agree that not everyone is on Java and using an ORM. But is it only useful for a single server? If you have multiple servers then you would also have a distributed second level cache which would eliminate the need for session pinning.

Re: JSON Web Tokens should be avoided

#270

Post by tracker1 »

tofflos wrote: post #269
tracker1 wrote: post #266

Earlier quoted context omitted.

Which will require session pinning for the load balancer, not to mention, I'm not using Java or a similar ORM. That will only help for a single instance of an application on a single server... not much help when you specifically don't want session pinning.

I agree that not everyone is on Java and using an ORM. But is it only useful for a single server? If you have multiple servers then you would also have a distributed second level cache which would eliminate the need for session pinning.

distributed, or duplicated... each server potentially making that DB request... depending on load adding at least 2-3ms, potentially more. If a given request to a single endpoint needs to touch a dozen more, not including resource lookups and when not everything is parallel... or across datacenters, from the colocated to aws, etc.. it all adds up.

Very short lived JWT mitigates this as the window for replay is reduced, over HTTPS by the time you can crack it, that window is effectively gone. The server can verify a signature on a JWT in a fraction of a second... far faster than a DB call... Not including replication issues.

Post reply on HN