4 ms·

These points are covered in the article, and the library I wrote makes it impossible to parse a token without performing verification with a secret key

jarym 9y ago
Yes I read. However, you've failed to grasp a few things: 1. The client should not get to 'choose' which algo it uses, it merely states what algo it did use. Emphasis should be on the server to verify that the client didn't do (or claim to do) something bad. 2. What happens if in 5 years time the algo you've standardised on is suddenly comprisable? You've ripped out the mechanism that updated clients could theoretically use to signify that they're using a newer algorithm. Take for example Git and its recent SHA collision issue. 3. By emphasising that 'clients should not get to choose', you're making the case that the choice is of itself a weakness it is not. The weakness is often in how inputs are processed (and far more often than any weakness in algorithms).
- kevinburke 9y ago
  I point out numerous cases where the server made a mistake in verifying the algorithm specified by the client. This is the point of reducing the complexity of the interaction If you are using JWT and someone breaks SHA2, you still have to worry about downgrade attacks. To evade downgrade attacks, you'll have to detect the protocol the client sends, and reject tokens that specify SHA2 or below. Or, roughly the same position you'd be in with one good algorithm: still in need of a backwards incompatible upgrade
  - politician 9y ago
    This concern was always supposed to be handled by algorithm whitelists. The _intent_ was that services would consult a whitelist of algorithms before accepting a particular JWT. The idea was certainly not that services blindly accept any token from every algorithm shipped in the library. Your browser supports TLS 1.0, should you throw it out? > If someone breaks SHA2... JWT has a built-in mechanism for handling this: expirations.
    - kevinburke 9y ago
      There's no "better TLS" out there for shipping a tool that connects to millions of different servers. There are many better options than JWT. Unlike JWT, hundreds of the world's best security engineers at various browser companies are working on mitigating the situation as well as possible.
      - politician 9y ago
        Indeed, however, consider that servers can and do limit which TLS versions and cipher suites they accept.
    - joepie91_ 9y ago
      Expirations are not really relevant to this. It won't prevent a user from forging new tokens with a different expiration (using a broken algorithm), nor will it somehow magically make the original token unreadable. The expiration is just an additional value in the payload that the implementation is supposed to check against.
- unscaled 9y ago
  That's how I always implemented JWT, but I'm pretty sure the lazy implementer would get that wrong. I'm with you that a protocol should include some versioning mechanism, but it probably shouldn't have as many knobs as JWT has right now. The decision to include RSA was misguided, and there's no point in letting users choose the size of the hash or whether to use key-wrapping or not (in JWE - the answer is always use key-wrapping with GCM when in doubt, 96 bits nonces are not long enough if you send many messages). There are other confusing knobs which shouldn't have been there. It's best to go the NaCl way and choose 1 algorithm considered best-in-class for each type of crypto, and leave space for adding new algorithms in the future when the old algorithm becomes compromised. Cypher breakdown events like Shapocalypse don't happen out of the blue. We usually get gradually improving attacks at least 5-10 years before that breakdown happens (SHA1 had weaknesses found as early as 2005).
exabrial 9y ago
Literally, someone has created poor implementations of TLS and SSL that have caused massive security issues for the world, (heartbleed, poodle, freak, beast) but you seem to have glossed over that detail and recommended it anyway.
- kevinburke 9y ago
  It's deployed onto billions of browsers already, and the only way to talk to e.g the Twitter API. We don't really have a choice about it. But if you want you can read tptacek on it: https://gist.github.com/tqbf/be58d2d39690c3b366ad https://gist.github.com/tqbf/be58d2d39690c3b366ad
  - exabrial 9y ago
    Side note: that's a cool list

jarym 9y ago

Yes I read. However, you've failed to grasp a few things: 1. The client should not get to 'choose' which algo it uses, it merely states what algo it did use. Emphasis should be on the server to verify that the client didn't do (or claim to do) something bad. 2. What happens if in 5 years time the algo you've standardised on is suddenly comprisable? You've ripped out the mechanism that updated clients could theoretically use to signify that they're using a newer algorithm. Take for example Git and its recent SHA collision issue. 3. By emphasising that 'clients should not get to choose', you're making the case that the choice is of itself a weakness it is not. The weakness is often in how inputs are processed (and far more often than any weakness in algorithms).

kevinburke 9y ago
I point out numerous cases where the server made a mistake in verifying the algorithm specified by the client. This is the point of reducing the complexity of the interaction If you are using JWT and someone breaks SHA2, you still have to worry about downgrade attacks. To evade downgrade attacks, you'll have to detect the protocol the client sends, and reject tokens that specify SHA2 or below. Or, roughly the same position you'd be in with one good algorithm: still in need of a backwards incompatible upgrade
- politician 9y ago
  This concern was always supposed to be handled by algorithm whitelists. The _intent_ was that services would consult a whitelist of algorithms before accepting a particular JWT. The idea was certainly not that services blindly accept any token from every algorithm shipped in the library. Your browser supports TLS 1.0, should you throw it out? > If someone breaks SHA2... JWT has a built-in mechanism for handling this: expirations.
  - kevinburke 9y ago
    There's no "better TLS" out there for shipping a tool that connects to millions of different servers. There are many better options than JWT. Unlike JWT, hundreds of the world's best security engineers at various browser companies are working on mitigating the situation as well as possible.
    - politician 9y ago
      Indeed, however, consider that servers can and do limit which TLS versions and cipher suites they accept.
  - joepie91_ 9y ago
    Expirations are not really relevant to this. It won't prevent a user from forging new tokens with a different expiration (using a broken algorithm), nor will it somehow magically make the original token unreadable. The expiration is just an additional value in the payload that the implementation is supposed to check against.
unscaled 9y ago
That's how I always implemented JWT, but I'm pretty sure the lazy implementer would get that wrong. I'm with you that a protocol should include some versioning mechanism, but it probably shouldn't have as many knobs as JWT has right now. The decision to include RSA was misguided, and there's no point in letting users choose the size of the hash or whether to use key-wrapping or not (in JWE - the answer is always use key-wrapping with GCM when in doubt, 96 bits nonces are not long enough if you send many messages). There are other confusing knobs which shouldn't have been there. It's best to go the NaCl way and choose 1 algorithm considered best-in-class for each type of crypto, and leave space for adding new algorithms in the future when the old algorithm becomes compromised. Cypher breakdown events like Shapocalypse don't happen out of the blue. We usually get gradually improving attacks at least 5-10 years before that breakdown happens (SHA1 had weaknesses found as early as 2005).

exabrial 9y ago

Literally, someone has created poor implementations of TLS and SSL that have caused massive security issues for the world, (heartbleed, poodle, freak, beast) but you seem to have glossed over that detail and recommended it anyway.

kevinburke 9y ago
It's deployed onto billions of browsers already, and the only way to talk to e.g the Twitter API. We don't really have a choice about it. But if you want you can read tptacek on it: https://gist.github.com/tqbf/be58d2d39690c3b366ad https://gist.github.com/tqbf/be58d2d39690c3b366ad
- exabrial 9y ago
  Side note: that's a cool list