4 ms·

Assuming that: - your JWT libraries don't do anything dumb like accepting the `none` algorithm - you're using HMAC SHA-256 - your access tokens have a short

by bgentry 10y ago

Assuming that: - your JWT libraries don't do anything dumb like accepting the `none` algorithm - you're using HMAC SHA-256 - your access tokens have a short (~20 min) expiration time - your refresh tokens are easily revocable Can you elaborate on the specific security advantages that a token encoded with ActiveSupport::MessageEncryptor would have over such a JWT implementation? Why do you think there aren't more AS::ME implementations out there if it's a superior solution? I only know of a Go implementation and haven't seen others: https://godoc.org/github.com/mattetti/goRailsYourself/crypto https://godoc.org/github.com/mattetti/goRailsYourself/crypto Edit I saw you mention Fernet in another comment. As a Heroku alum I'm quite familiar with Fernet (we used it for lots of things), but to my knowledge those projects are on life support at best.

unscaled 10y ago
You should also make sure to allow only tokens with the "HS256" alg headers before you verify them, in case somebody decides to add a new signature algorithm to your library, and it turns out it could easily be broken and lets you use the same key you used for HS256.
- bgentry 10y ago
  yes, that's another good point and probably something many folks mess up. I am explicitly specifying my algorithm for both encode/decode :)
- tracker1 10y ago
  If it's your software generating the tokens, then that means they'd need the shared key, or private key in order to sign the token... which is already a problem. Now if you're accepting tokens from a third party, that's another issue, and should be much more constrained. I go farther still and require a VERY short expiration on service to service requests (documented as 1m, coded as 2m) which combined with https limits the chance of replay attacks.
cainlevy 10y ago
> using HMAC SHA-256 HMAC is great for monolithic architecture, but I've quite enjoyed using asymmetric RS256. I don't think that's something AS::ME offers.
Zombieball 10y ago
I'd also be interested in hearing an answer to this from tptacek. My (limited) understanding is the security issues arise around the implementation & handling some of the default claims (NBF, IAT, etc.) and producing/verifying the signature. But I don't quite understand how moving to a different format solves these issues?

by bgentry 10y ago

unscaled 10y ago

You should also make sure to allow only tokens with the "HS256" alg headers before you verify them, in case somebody decides to add a new signature algorithm to your library, and it turns out it could easily be broken and lets you use the same key you used for HS256.

bgentry 10y ago
yes, that's another good point and probably something many folks mess up. I am explicitly specifying my algorithm for both encode/decode :)
tracker1 10y ago
If it's your software generating the tokens, then that means they'd need the shared key, or private key in order to sign the token... which is already a problem. Now if you're accepting tokens from a third party, that's another issue, and should be much more constrained. I go farther still and require a VERY short expiration on service to service requests (documented as 1m, coded as 2m) which combined with https limits the chance of replay attacks.

cainlevy 10y ago

> using HMAC SHA-256 HMAC is great for monolithic architecture, but I've quite enjoyed using asymmetric RS256. I don't think that's something AS::ME offers.

Zombieball 10y ago

I'd also be interested in hearing an answer to this from tptacek. My (limited) understanding is the security issues arise around the implementation & handling some of the default claims (NBF, IAT, etc.) and producing/verifying the signature. But I don't quite understand how moving to a different format solves these issues?