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

How to Use JSON Web Tokens

github.com

Post reply on HN
Print view View original

81–90 of 135 posts

Re: How to Use JSON Web Tokens

#81

Post by andrewstuart2 »

jka wrote: post #40
KaiserPro wrote: post #17

JWTs are useful, but there are a few things that are not immediately obvious. 1) They are signed not encrypted. Anything you put in there is public readable, unless you encrypt your token after you generate it 2) you can accept a range of encryption types, don't. Stick to one type and disallow any token that doesn't conform (this protects against people making their own tokens with 'None' as the signing algorithm) I…

There are also a number of easy-to-make mistakes or gaps which can be introduced with the use of JWTs. https://twitter.com/ejcx_/status/1063846166029197312 provides a great list of test cases covering the commonly reoccurring flaws. The number and seriousness of these errors and how easy it is to make them does raise questions about how sensible it is to use JWT, unless you're really sure about what you're doing.

There are a number of easy-to-make mistakes with all security software. That doesn't mean it's not worth using; it just means that we should build the tooling we need in the open as shared software, so that the wisdom of crowds prevails.

Almost exactly the same set of problems exists with signed x509 certificates, but I doubt anybody would tell you not to use them. They'd just say "make sure you don't implement your own validation, unless you absolutely have to, which you don't, and even then only with lots and lots of review/audits." The wisdom with JWT should be the same, IMO.

Re: How to Use JSON Web Tokens

#82

Post by kevinburke »

Last year I helped several different companies switch off of JWT onto JSON encrypted with secretbox, which was much more appropriate for their use case(s). No risk of accidentally using an insecure algorithm or sending secure data unencrypted to the client.

Local storage is not secure.

Re: How to Use JSON Web Tokens

#83

Post by amenod »

superasn wrote: post #47

One of the biggest advantages of JWT is that is saves up on database reads which can be significant when you have million+ logged in users. I think that is probably thinking of time when you had to do everything yourself (host your own mysql server, create indexes, cache, etc). Now you can easily save your sessions using stuff like DynamoDb.. it costs almost nothing and read times are blazing fast even when there are…

> Now you can easily save your sessions...

True.

> ...using stuff like DynamoDb..

Well, yeah, if you want to be tied to AWS and use a difficult to manage technology which is only useful in a few niche cases, DynamoDB is absolutely the right choice . Otherwise Redis, Memcache or even Postgres would be a better choice. After all, session management is only a (small) part of data persistence problem.

Re: How to Use JSON Web Tokens

#84

Post by kevinburke »

andrewstuart2 wrote: post #81
jka wrote: post #40

Earlier quoted context omitted.

There are also a number of easy-to-make mistakes or gaps which can be introduced with the use of JWTs. https://twitter.com/ejcx_/status/1063846166029197312 provides a great list of test cases covering the commonly reoccurring flaws. The number and seriousness of these errors and how easy it is to make them does raise questions about how sensible it is to use JWT, unless you're really sure about what you're doing.

There are a number of easy-to-make mistakes with all security software. That doesn't mean it's not worth using; it just means that we should build the tooling we need in the open as shared software, so that the wisdom of crowds prevails. Almost exactly the same set of problems exists with signed x509 certificates, but I doubt anybody would tell you not to use them. They'd just say "make sure you don't implement your…

Saying "all security software has flaws" advantages the software with the most flaws and disadvantages the software with the fewest number of flaws. There are many, many better solutions for the problem JWT solves, there are not many better solutions for X509, which is why people keep using X509.

It is significantly more difficult to misuse e.g. golang.org/x/crypto/nacl/secretbox than JWT.

Re: How to Use JSON Web Tokens

#85

Post by incadenza »

geezerjay wrote: post #73
incadenza wrote: post #50

Earlier quoted context omitted.

My issue here is that expiring JWTs involve adding state! The whole point of JWTs is stateless authentication, so I’ve never understood the advantage over sessions unless revoking tokens is never an option.

> My issue here is that expiring JWTs involve adding state! I don't agree. The expiration timestamp is not a state, nor is a nonce/token id. Moreover the specs enable servers to arbitrarily reject tokens, which means servers can arbitrarily request token refreshes. This means that any argument regarding how a nonce is a state is entirely irrelevant and without any practical interest.

Why would you arbitrarily reject a token refresh? The question here is which token to reject. That's where the state comes in. If a token is compromised, you have to know which one. Hence, stateful.

Re: How to Use JSON Web Tokens

#86

Post by CiPHPerCoder »

StevePerkins wrote: post #21
fastbeef wrote: post #3

Earlier quoted context omitted.

I keep hearing this. Is there a good writeup available?

Most of the "discussion" on this topic spins out of this blog post: https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba... . Which unfortunately is: 1. A bit unnecessarily abrasive and hysterical in its style, and 2. Comes from a PHP consulting firm, promoting their own alternative proposal (which hardly anyone else seems to discuss or use). So I think #1 above is really about drawing eyeballs and selling se…

> Comes from a PHP consulting firm, promoting their own alternative proposal (which hardly anyone else seems to discuss or use). So I think #1 above is really about drawing eyeballs and selling services, more so than providing clear information for a newcomer to follow.

There was a recent (November 2018) talk at London Gophers about JWT Alternatives (slides here: https://speakerdeck.com/hako/exploring-alternatives-to-json-...).

Keep in mind that PASETO didn't exist until the middle of 2018, so the main reason "hardly anyone else" seems to use it is precisely because it takes time for standards to be adopted.

If you take a look at https://paseto.io, you'll see that there are implementations of PASETO (our proposed alternative) in multiple programming languages by other companies and individuals. All of these implementations are open source and under very permissive licenses (MIT or ISC).

Additionally, a great deal of time and effort went into the PASETO documentation, so that developers can understand not only how to implement it themselves, but also why it was designed the way it is. https://github.com/paragonie/paseto/tree/master/docs

Given all of the above, is it really fair to write PASETO off as an attempt to sell services?

Claiming that the original article is meant to sell services doesn't make sense either: If developers keep using unsafe tools, they will continue to be less secure and I'll have an easier time selling "make your products/services more secure" services to developers. The best thing to do, to meet such an incentive, is to say nothing publicly and let the easy money keep rolling in.

So one of two things is happening:

1. You don't correctly understand our intentions.

2. We're really bad at understanding our own incentives, and it's a miracle we've been in business for 4 years.

Re: How to Use JSON Web Tokens

#87

Post by superasn »

amenod wrote: post #83
superasn wrote: post #47

One of the biggest advantages of JWT is that is saves up on database reads which can be significant when you have million+ logged in users. I think that is probably thinking of time when you had to do everything yourself (host your own mysql server, create indexes, cache, etc). Now you can easily save your sessions using stuff like DynamoDb.. it costs almost nothing and read times are blazing fast even when there are…

> Now you can easily save your sessions... True. > ...using stuff like DynamoDb.. Well, yeah, if you want to be tied to AWS and use a difficult to manage technology which is only useful in a few niche cases, DynamoDB is absolutely the right choice . Otherwise Redis, Memcache or even Postgres would be a better choice. After all, session management is only a (small) part of data persistence problem.

Yes of course. That was not my point DynamoDb was just something off the top of my head. You can easily use redis or even any nosql db for that. My point was about the main advantages of JWT being fast with millions of users isn't really that big deal anymore.

Re: How to Use JSON Web Tokens

#88

Post by geezerjay »

incadenza wrote: post #85
geezerjay wrote: post #73

Earlier quoted context omitted.

> My issue here is that expiring JWTs involve adding state! I don't agree. The expiration timestamp is not a state, nor is a nonce/token id. Moreover the specs enable servers to arbitrarily reject tokens, which means servers can arbitrarily request token refreshes. This means that any argument regarding how a nonce is a state is entirely irrelevant and without any practical interest.

Why would you arbitrarily reject a token refresh? The question here is which token to reject. That's where the state comes in. If a token is compromised, you have to know which one. Hence, stateful.

> Why would you arbitrarily reject a token refresh?

You've misread what I've said. The server can trigger token refreshes by rejecting the request. According to the JWT workflow, that triggers the client to request a new token and retry the request.

> The question here is which token to reject.

That isn't much of a question, because servers are free to reject any token arbitrarily. They can, however, ignore specific tokens that cease to be valid, such as expired tokens or tokens which have already been used. None of those scenarios involves any change to the token's state.

Re: How to Use JSON Web Tokens

#89

Post by andrewstuart2 »

kevinburke wrote: post #84
andrewstuart2 wrote: post #81

Earlier quoted context omitted.

There are a number of easy-to-make mistakes with all security software. That doesn't mean it's not worth using; it just means that we should build the tooling we need in the open as shared software, so that the wisdom of crowds prevails. Almost exactly the same set of problems exists with signed x509 certificates, but I doubt anybody would tell you not to use them. They'd just say "make sure you don't implement your…

Saying "all security software has flaws" advantages the software with the most flaws and disadvantages the software with the fewest number of flaws. There are many, many better solutions for the problem JWT solves, there are not many better solutions for X509, which is why people keep using X509. It is significantly more difficult to misuse e.g. golang.org/x/crypto/nacl/secretbox than JWT.

I never said "all security software has flaws," since that has a substantially different meaning than my comment.

While I'm not arguing with your statement regarding ease of misuse, you should also consider the trade-offs. It's also significantly easier to misuse a pocket knife than a butter knife for the same reason. Butter knives are designed for a small set of problems and deliberately have duller edges to avoid some of the potential downsides of pocket knives. That doesn't make pocket knives useless, it just means that you might need to be trained on safely using a pocket knife, whereas I'm totally comfortable handing a butter knife to my four-year-old. If you're going to be trusted with security, you're really going to need either a) a sharper knife, or b) to understand which knives you're okay handing to your coworkers, or c) to be able to train your coworkers on proper knife safety so they can also use the more flexible tools, but still safely.

Re: How to Use JSON Web Tokens

#90

Post by groestl »

jondubois wrote: post #42

I think storing JWTs might make sense for some advanced scenarios where you have multiple services with varying security requirements but when you store JWTs, you lose a lot of the benefits of having a stateless token which doesn't require a database lookup. A possible alternative is to just make the JWT expiry very short; like one hour; then you don't really need to explicitly invalidate the token. With a real time…

An hour could be much much too long, depending on what service you are protecting. It's long enough that even assuming that token theft is a non-stealthy operation, and the user reacts immediately, the attacker has a lot of time to execute his attack. For things like Facebook, this could include slowly scaping all user data and spreading the infection vector to other users.

As for websockets: session integrity is handled by TLS, and invalidation can be handled by closing the TCP connection. Authentication needs to happen only once, on connect.

Post reply on HN