5 ms·

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

mrighele 9y 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.
- theprotocol 9y ago
  >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.
  - kobeya 9y ago
    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.
- kevinburke 9y ago
  The spec requires you to implement the "none" algorithm IIRC.
  - mrighele 9y ago
    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 https://tools.ietf.org/html/rfc7519
cappie013 9y ago
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.
- theprotocol 9y ago
  You could even hit 2 birds with 1 stone by going with headerless JWTs (just strip the first segment).
  - Freak_NL 9y ago
    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).
    - theprotocol 9y ago
      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.
      - vertex-four 9y ago
        Symmetric signing is not, by far, the only use case for JWTs. Asymmetric signing, and encryption, are also well-specified and supported.
        theprotocol 9y ago
        Good point! It slipped my mind.

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.

theprotocol 9y ago
>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.
- kobeya 9y ago
  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.
kevinburke 9y ago
The spec requires you to implement the "none" algorithm IIRC.
- mrighele 9y ago
  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 https://tools.ietf.org/html/rfc7519

cappie013 9y ago

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.

theprotocol 9y ago
You could even hit 2 birds with 1 stone by going with headerless JWTs (just strip the first segment).
- Freak_NL 9y ago
  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).
  - theprotocol 9y ago
    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.
    - vertex-four 9y ago
      Symmetric signing is not, by far, the only use case for JWTs. Asymmetric signing, and encryption, are also well-specified and supported.
      - theprotocol 9y ago
        Good point! It slipped my mind.