Hacker News Reader

Hacker News

Comment by sergior | Hacker News Reader

Full thread

sergior

hey, author is missing the bit where you can disallow client to choose the algorithm. No need to read the rest...

View on HN

In some way he addresses that towards the end:

> It's important to note that my experiment is not JWT.

> When you reduce JWT to a thing that is secure,

> you give up the "algorithm agility" that is a proud part

> of the specification.

I don't agree with him though, unless the standard requires to implement all of the available algorithms, one may choose to implement only those that he/she deems safe/worth.

>I don't agree with him though, unless the standard requires to implement all of the available algorithms, one may choose to implement only those that he/she deems safe/worth.

Agreed. I view this flexibility as a developer feature, not a client feature.

Correct. Let's say you implement RSA2048 and server-side reject all other algorithms. Then during a security audit the crypto guy points out that RSA2048, while not broken per se, is not up to the generally-accepted 128-bit security threshold. You should use RSA-3078+ or switch to ECDSA. You decide to switch to ECDSA for the space savings. But what about all the deployed clients? Well since it's not actually broken, you continue to accept RSA-2048 for the next couple of years until something else permanently breaks support for old clients. Supporting client-specified algorithms lets you do a safe, phased-in upgrade without breaking compatibility or any fancy engineering.

The spec requires you to implement the "none" algorithm IIRC.

From a cursory read from the specs [1] I can see the following (Chapter 7.2):

> Finally, note that it is an application decision which algorithms may

> be used in a given context. Even if a JWT can be successfully

> validated, unless the algorithms used in the JWT are acceptable to

> the application, it SHOULD reject the JWT.

From what I understand from the above, the server side can decide to _always_ reject the "none" algorithm and still qualify as a valid implementation. The fact that the "none" algorithm is implemented or not by the library becomes a detail.

[1] https://tools.ietf.org/html/rfc7519

Exactly what I was thinking while reading the article.

I'm using JWT for an API, and the server is choosing which algorithm to chose.

Really don't understand why a client should bypass server.

You could even hit 2 birds with 1 stone by going with headerless JWTs (just strip the first segment).

Keeping the JWT format as-is is useful if you have signed (but not encrypted) tokens though; in a web browser you can use standard libraries to inspect the token and alter the UI based on a user's permissions (the final check is always the API's responsibility of course, but if there is no need to show the 'admin' link the client can do that).

If it isn't encrypted, the only thing the client needs to know is that it's base64 encoded in order to inspect it. You'd need the secret to verify the signing and you probably shouldn't have that on the client-side!

So I still think the header is superfluous even for this use case.

edit: in fact, the client needs to know that it's base64 encoded to even read the header in the first place.

Symmetric signing is not, by far, the only use case for JWTs. Asymmetric signing, and encryption, are also well-specified and supported.

Good point! It slipped my mind.

There's some value in the header. Google use it to store the keyid, which is pretty useful.

You can run into issues with headerless JWTs when you can't (or don't) guarantee the order of the header. Since the header is included in the signature of JWS objects, you must reattach a header that is exactly the same, and not just equivalent.

For example, both of these decoded headers are equivalent:

{ "alg": "HS256", "typ": "JWT" }

{ "typ": "JWT", "alg": "HS256" }

Obviously, these encode to two different values. If you reattach the wrong one, signature verification will fail.

Disclaimer: I maintain a Python JOSE library and have had to answer questions related to this on more than one occasion.

The question is: what if you change the algorithm on the server, and a user still has an old token.

Usually you don't care (as in will never happen), but on the off chance you do, you have to do 2 deploys, 1 to add the new thing and another one to remove the old thing.

This is pretty standard for rolling signing keys and api auth methods and all kinds of stuff like that.

Definitely, and it’s how I’d do it as well, but the standard was written for the use case of companies on the scale of Google.

Which still support webbrowsers that were released before 2007. (But somehow, they can’t support Firefox Mobile. mmhhmk. Totally not a plot to get rid of mobile ad blocking.)

Or if the old approach is no longer trusted, simply refuse old tokens. Any users with the old tokens will simply be forced to re-authenticate.

So, let's say you're currently using RS256 JWTs, and you want to migrate to ES256. Your JWTs are stored by clients in various places - some of them might be short-term, some long-term, so you don't want to invalidate old ones (RS256 isn't broken yet).

How do you tell RS256 and ES256 JWTs apart - so you can figure out how to validate them - unless the JWT actually encodes that information?

The trick is that JWT APIs need to force developers to choose which algorithms they want - having a `decode_jwt` function is not a good idea, `decode_es256_jwt` is much better. It'd validate that the alg in the header is correct, and return a specific error if it's not - if that error is returned, the developer can try `decode_rs256_jwt`.

This is how I've designed the API used in my OpenID Connect implementation. It works wonderfully.

Reply on news.ycombinator.com