Hacker News new | ask | show | jobs
by mrighele 3325 days ago
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.

2 comments

>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