Live data from Hacker News

How to Use JSON Web Tokens

github.com

131–135 of 135 posts

Re: How to Use JSON Web Tokens

#131
post #115

Earlier quoted context omitted.

You're right. Doing encryption correctly can be incredibly difficult and complex. Enough so that people might miss important subtleties of the technologies at hand. For instance, you may want the encryption of data-in-transit to be removed by the application, rather than by whatever is responsible for TLS termination. You may not want your load balancer to be capable of reading the most sensitive data of your request…

IDK what the details are there, but if you trust your TLS termination point with most data, it seems like you'd trust it with the JWT payload too.

I understand why a person might opt to think in that way! It's an obvious approach when people fully trust every part of their systems.

It's perhaps possible some might differ, especially in a context where limiting trust and misuse-resistance are concerns. Giving people the choice of encrypting or signing or both could seen by some as potentially less than maximally misuse-resistant.

Re: How to Use JSON Web Tokens

#132
post #83

Earlier quoted context omitted.

> 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.

Cool, sorry if I jumped the gun... I recently had to deal with some SW using DynamoDB for no special reason, so I'm a bit touchy about it. :)

Re: How to Use JSON Web Tokens

#133
post #68

Earlier quoted context omitted.

When someone's account is compromised, is another situation.

> When someone's account is compromised, is another situation. Why is that scenario relevant if tokens are supposed to be used once per request and short-lived? Once a token is used, it's supposed to be expired and no longer in use. Both the expiry timestamp and the nonce fields already handle those use cases.

Suppose to be once per request and short-lived. But that's not specified in the thread above.

Previous person mentioned logout, so I assumed we were talking about session tokens--which I understand its a misuse of JWTs--and is why he/she's mentioning it.

But if we're talking about just one time auth tokens, then yeah, you don't need expiry ahead of the expiry time, and it's plain it's a non-issue.

Re: How to Use JSON Web Tokens

#134

Earlier quoted context omitted.

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…

I mean, your homepage is pretty damn lacking and you even put something like this without putting any sources 'This has led to many security experts declaring boldly, "Don't use JWT!"'. This just looks like a poor attempt at making something 'better'.

Re: How to Use JSON Web Tokens

#135
post #134

Earlier quoted context omitted.

> 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…

I mean, your homepage is pretty damn lacking and you even put something like this without putting any sources 'This has led to many security experts declaring boldly, "Don't use JWT!"'. This just looks like a poor attempt at making something 'better'.

> I mean, your homepage is pretty damn lacking

Do you honestly believe cybersecurity decisions should come down to how snazzy a homepage is, rather than a company's reputation?

> and you even put something like this without putting any sources

That article being discussed in this thread in particular quotes:

1. The opinions of other security experts

2. RFC 7515, section 4.1.1

3. The auth0 article about RS256/HS256 confusion

4. RFC 7518

5. The Adobe attack on ECDH-ES

What additional kind of sources do you need? The arguments should be sufficiently supported by the material available.

> This just looks like a poor attempt at making something 'better'.

By what metrics could we make this attempt less "poor"? What specific changes do you need to see?

Post reply on HN