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

251–260 of 304 posts

Re: JSON Web Tokens should be avoided

#251

Post by theptip »

Alex3917 wrote: post #244
theptip wrote: post #240

Earlier quoted context omitted.

So every user on your system has to reauthenticate if one client token is compromised? That seems like an invitation to a thundering herd. Not necessarily fatal, but I'd consider it a nice feature to not have to invalidate everybody's tokens to get at one.

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

Got it, didn't catch that you were referring to storing that timestamp per-user.

That's what I do in my system.

Re: JSON Web Tokens should be avoided

#252

Post by Illniyar »

deathanatos wrote: post #173
Illniyar wrote: post #110

Earlier quoted context omitted.

Cookies are just string in a header. The difference is that unlike normal headers browesers treat cookie headers in a special way. They automatically add and remove keys from it, and they allow the server to set the header in a way that the client can neither see it nor change it (http only headers)

The downside being that the browser will attach it to every request; if you use cookies, you MUST be aware of this, or you are (IMO) pretty much guaranteed to write a CSRF vuln. (I'm much more in the localStorage + Authorization header for this reason. I recommend [1] for reading. If malicious JS is running, cookies won't save you, since the malicious JS is capable of simply making the request itself, to which the co…

CSRF is the easiest vulnerability to avoid, a csrf token solves all csrf attacks.

XSS is a lot harder to protect against, one of the better ways to mitigate it's effects is to use http only cookies

Re: JSON Web Tokens should be avoided

#253

Post by hdhzy »

Can anyone comment if TLS Token Binding [0] does solve some subset of problems usually solved with JWT?

It seems to be scheduled for implementation in several clients [1].

[0]: https://tools.ietf.org/html/draft-ietf-tokbind-protocol-13

[1]: https://www.chromestatus.com/feature/5097603234529280

Re: JSON Web Tokens should be avoided

#254

Post by mst »

tptacek wrote: post #208
mst wrote: post #201

Earlier quoted context omitted.

Seems like, practically, that suggests three options: 1. Take something like AS::ME that already has real use and implement it for as many platforms as possible 2. Define a really restricted subset of JWT (which may be necessary anyway for purposes of saying to management "yes, we're buzzword compliant") 3. Invent a non-AS::ME "bag-of-attributes secure bearer token" system and implement it everywhere. I think part of…

Or just use Fernet: https://github.com/fernet/spec/blob/master/Spec.md Fernet was written originally for Python but there's a Ruby implementation, a Golang implementation, and a Clojure implementation. I believe that for at least 80% of applications considering JWT, Fernet provides exactly the right amount of functionality, and does so far more safely than JWT.

This looks very much like the approach to session-data-in-encrypted-and-signed-cookie I've seen used to great success in lots of places (where for a stateless-ish API the contents are just a user id or whatever).

Am I right that this would work fine both in that or in e.g. a query parameter?

(sorry if I'm asking really stupid questions, but I'd rather look stupid than accidentally a security hole)

Re: JSON Web Tokens should be avoided

#255

Post by CiPHPerCoder »

StevePerkins wrote: post #70

The criticisms of JWT seem to fall into two categories: (1) Criticizing vulnerabilities in particular JWT libraries, as in this article. (2) Generally criticizing the practice of using any "stateless" client tokens. Because there's no great way to revoke them early while remaining stateless, etc. The problem is that both of these groups only criticize, neither of them can ever seem to actually recommend any alternati…

> (1) Criticizing vulnerabilities in particular JWT libraries, as in this article.

The purpose of this article it criticize the standard, not particular libraries.

Re: JSON Web Tokens should be avoided

#256

Post by je42 »

tptacek wrote: post #86
asanso wrote: post #78

The author of http://blog.intothesymmetry.com/2017/03/critical-vulnerabili... here FWIW. Personally I would not be so drastic. JOSE per se is not too bad (at least the idea is cool). Some crypto choices though have been really arguable...

That post is great work. Thanks again. But I think you're wrong about JWT. The problem with JWT/JOSE is that it's too complicated for what it does. It's a meta-standard capturing basically all of cryptography which, as you've ably observed (along with Matthew Green), was not written by or with cryptographers. Crypto vulnerabilities usually occur in the joinery of a protocol. JWT was written to maximize the amount of…

> The ability to negotiate different ciphers dynamically is an own-goal. And JWT doesn't prescribe a negotiation.

Re: JSON Web Tokens should be avoided

#257

Post by draw_down »

fcvarela wrote: post #136
draw_down wrote: post #74

Earlier quoted context omitted.

> Why would an issuer ever let a client decide what algo to use? Right, so, why is this in the spec?

The spec doesn't govern what applications can and cannot accept, it governs what contents are valid in tokens. 'None' is valid, that means my parser library will accept it, it doesn't mean my application must accept the token as valid. Example: The fact that my service has an http stack which must parse a cookie header doesn't mean my app must accept its contents as valid. There's a lot of confusion on this thread ab…

I guess I'm missing something here because it seems like the spec includes an ability that everyone here is saying nobody should ever use. Seems useless, by definition!

Re: JSON Web Tokens should be avoided

#258

Post by joepie91_ »

andy_ppp wrote: post #62
BinaryIdiot wrote: post #2

Well how about that; I had no idea there was a specific standard for this type of thing nor did I realize the client could specifically request a type of algorithm to be used. That seems incredibly short sighted; why wouldn't you let the server handle that and make the algorithm completely transparent? > Just use cookies over HTTPS. Maybe it's because of my experience working in environments where cookies were disabl…

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.

Re: JSON Web Tokens should be avoided

#259

Post by jdmichal »

tracker1 wrote: post #241
jdmichal wrote: post #172

Earlier quoted context omitted.

I can make an attempt at an alternative: Distribute signing and encryption keys to all servers. Have them encrypt and sign the outgoing serialized token, whatever that consists of. Have them verify and decrypt the incoming token. This is just straight-forward cryptography, with keys known only to the server, so I'm pretty sure you won't get any arguments from (1). (And, I suppose the encryption could even be skipped,…

And if you want to be able to authenticate users to a service that you do not want to send private keys to?

Then sign / encrypt the token with a private key and distribute a public key to the untrusted peers. Since you're just using bog-standard cryptography primitives you can change them at will to match your use case. Need to handle untrusted peers? Asymmetric keys are the answer.

Re: JSON Web Tokens should be avoided

#260

Post by igl »

Alex3917 wrote: post #244
theptip wrote: post #240

Earlier quoted context omitted.

So every user on your system has to reauthenticate if one client token is compromised? That seems like an invitation to a thundering herd. Not necessarily fatal, but I'd consider it a nice feature to not have to invalidate everybody's tokens to get at one.

> 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?
Post reply on HN