4 ms·

Issues like this aside, why couldn't they just design it using AES-GCM or whatever authenticated encryption scheme instead of AES + MAC? There is literally no

by verroq 11y ago

Issues like this aside, why couldn't they just design it using AES-GCM or whatever authenticated encryption scheme instead of AES + MAC? There is literally no reason to use encrypt + MAC when there are authenticated encryption schemes available.

tracker1 11y ago
I think the original intent of the spec was to allow some flexibility... in practice supporting this flexibility lead to some vulnerabilities. In this case, when you're expecting tokens using public/private pairs for signing tokens and a client library also supports a different signing method, you can forge a token targetting a specific client. The purpose of having a signature method was to have a fast system in place for being able to verify a token per request... fully encrypted tokens have slightly more overhead when there will be a lot of small requests... though you can also use an in-memory, or simething like redis to have a cache of pre-hashed tokens on the same system, which would reduce at least some overhead for the validation. As I mentioned in my own post, JWT is easy enough to implement an expected methodology, when you are only supporting a single authority, that I hadn't even considered the problem mentioned in the article, I'd actually ignored the header part for my own use.
- rockdoe 11y ago
  I think the original intent of the spec was to allow some flexibility... in practice supporting this flexibility lead to some vulnerabilities. I think less than a week ago (weakdh) tptacek was mentioning on twitter that security schemes should be versioned but not extensible exactly due to these kind of errors.
  - SFjulie1 11y ago
    This was predicted http://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/ http://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-h... Oauth 2.0 is so much of a flexible framework it almost boils down to "roll your own crypto with very complex tools and a lot of moving parts" I am gonna watch the world burn safely eating my popcorn with my old fashions AAA system (radius, LDAP, ssh..) expecting more vulnerabilities to be uncovered and waiting for employers and architects to require my now valuable knowledge. Mouhahahahahahha
- billyhoffman 11y ago
  "I think the original intent of the spec was to allow some flexibility... in practice supporting this flexibility lead to some vulnerabilities." This statement applies to roughly half of all security issues I have ever seen. I'm not making a joke or being flippant, and it reenforces what you need to consider when designing specs or APIs. Specs have surface area just like code does, and decreasing it often has positive outcomes for security.

by verroq 11y ago

tracker1 11y ago

I think the original intent of the spec was to allow some flexibility... in practice supporting this flexibility lead to some vulnerabilities. In this case, when you're expecting tokens using public/private pairs for signing tokens and a client library also supports a different signing method, you can forge a token targetting a specific client. The purpose of having a signature method was to have a fast system in place for being able to verify a token per request... fully encrypted tokens have slightly more overhead when there will be a lot of small requests... though you can also use an in-memory, or simething like redis to have a cache of pre-hashed tokens on the same system, which would reduce at least some overhead for the validation. As I mentioned in my own post, JWT is easy enough to implement an expected methodology, when you are only supporting a single authority, that I hadn't even considered the problem mentioned in the article, I'd actually ignored the header part for my own use.

rockdoe 11y ago
I think the original intent of the spec was to allow some flexibility... in practice supporting this flexibility lead to some vulnerabilities. I think less than a week ago (weakdh) tptacek was mentioning on twitter that security schemes should be versioned but not extensible exactly due to these kind of errors.
- SFjulie1 11y ago
  This was predicted http://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/ http://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-h... Oauth 2.0 is so much of a flexible framework it almost boils down to "roll your own crypto with very complex tools and a lot of moving parts" I am gonna watch the world burn safely eating my popcorn with my old fashions AAA system (radius, LDAP, ssh..) expecting more vulnerabilities to be uncovered and waiting for employers and architects to require my now valuable knowledge. Mouhahahahahahha
billyhoffman 11y ago
"I think the original intent of the spec was to allow some flexibility... in practice supporting this flexibility lead to some vulnerabilities." This statement applies to roughly half of all security issues I have ever seen. I'm not making a joke or being flippant, and it reenforces what you need to consider when designing specs or APIs. Specs have surface area just like code does, and decreasing it often has positive outcomes for security.