4 ms·

Seems like, practically, that suggests three options: 1. Take something like AS::ME that already has real use and implement it for as many platforms as possibl

by mst 10y ago

Seems like, practically, that suggests three options: 1. Take something like AS::ME that already has real use and implement it for as many platforms as possible 2. Define a really restricted subset of JWT (which may be necessary anyway for purposes of saying to management "yes, we're buzzword compliant") 3. Invent a non-AS::ME "bag-of-attributes secure bearer token" system and implement it everywhere. I think part of the trouble with 3 is that people like me genuinely worry that if we tried to roll our own we'd manage to do worse than JWT in spite of JWT being terrible. So maybe step zero is for somebody with crypto knowledge to explain one sane way to do the "bag-of-attributes secure bearer token" part ... or you to point the audience to a blog post that already exists that describes it, because, well, because I suspect quite a few of us trust you to say "this post actually describes a sensible plan" while we don't trust ourselves to be able to tell.

tptacek 10y ago
Or just use Fernet: https://github.com/fernet/spec/blob/master/Spec.md https://github.com/fernet/spec/blob/master/Spec.md Fernet was written originally for Python but there's a Ruby implementation, a Golang implementation, and a Clojure implementation. I believe that for at least 80% of applications considering JWT, Fernet provides exactly the right amount of functionality, and does so far more safely than JWT.
- mst 10y ago
  This looks very much like the approach to session-data-in-encrypted-and-signed-cookie I've seen used to great success in lots of places (where for a stateless-ish API the contents are just a user id or whatever). Am I right that this would work fine both in that or in e.g. a query parameter? (sorry if I'm asking really stupid questions, but I'd rather look stupid than accidentally a security hole)
- Flenser 10y ago
  Since it's not linked from any https://github.com/fernet/ https://github.com/fernet/ project as far as I could tell, and I had to google for it. Clojure implementation: https://github.com/derwolfe/fernet-clj https://github.com/derwolfe/fernet-clj I also found a JavaScript implementation: https://github.com/csquared/fernet.js https://github.com/csquared/fernet.js
cainlevy 10y ago
1. The reason AS::ME can be that nice is because it assumes a monolithic architecture and a single framework. For example, AS::ME relies on shared secrets, which I think makes it unfit for distributed systems. Implementing JWK with asymmetric keys can really reduce provisioning and configuration costs. Keeping the signing secret on one private, hardened auth server (or cluster) also allows smart things like automated key rotation. 2. 100%. There's at least one right way to do JWT, but more ways to do JWT wrong. 3. JWT et al provide a fine starting point, I don't see a reason to start from scratch. I'm not tied to the JWT spec, but I'm quite happy with what I've been able to accomplish using a careful implementation in my AuthN server: https://github.com/keratin/authn https://github.com/keratin/authn
- tracker1 10y ago
  Agreed... my first two experiences with JWT were creating my own implementation... in my case, the allowed public keys had to come via https from a specific server in the domain, even without PKI using shared key... I had hard coded the algorithm used for the signature. This could just as easily be filters on a library though, it's just my first experience didn't have a valid library, so I had to composite one (did use existing crypto library though). JWT is a perfectly valid structure, even if the spec is more flexible than it should be. By that matter, https also has historically supported algorithms and protocols later broken. Nobody is suggesting we stop use HTTPS, only that we limit acceptable protocol and algorithms supported.
  - tptacek 10y ago
    No, almost everybody in the field laments SSL and TLS. It's probably too late at this point --- and has been for well over a decade --- to get to something better than TLS, and so TLS 1.3 is what we're stuck with. But that is demonstrably not the case with JWT. We don't have to convince all the browser vendor to upgrade out of JWT in lockstep. Avoiding another 20 years of hair-on-fire crypto vulnerabilities seems reason enough to lobby against that spec.
    - tracker1 10y ago

by mst 10y ago

tptacek 10y ago

Or just use Fernet: https://github.com/fernet/spec/blob/master/Spec.md https://github.com/fernet/spec/blob/master/Spec.md Fernet was written originally for Python but there's a Ruby implementation, a Golang implementation, and a Clojure implementation. I believe that for at least 80% of applications considering JWT, Fernet provides exactly the right amount of functionality, and does so far more safely than JWT.

mst 10y ago
This looks very much like the approach to session-data-in-encrypted-and-signed-cookie I've seen used to great success in lots of places (where for a stateless-ish API the contents are just a user id or whatever). Am I right that this would work fine both in that or in e.g. a query parameter? (sorry if I'm asking really stupid questions, but I'd rather look stupid than accidentally a security hole)
Flenser 10y ago
Since it's not linked from any https://github.com/fernet/ https://github.com/fernet/ project as far as I could tell, and I had to google for it. Clojure implementation: https://github.com/derwolfe/fernet-clj https://github.com/derwolfe/fernet-clj I also found a JavaScript implementation: https://github.com/csquared/fernet.js https://github.com/csquared/fernet.js

cainlevy 10y ago

1. The reason AS::ME can be that nice is because it assumes a monolithic architecture and a single framework. For example, AS::ME relies on shared secrets, which I think makes it unfit for distributed systems. Implementing JWK with asymmetric keys can really reduce provisioning and configuration costs. Keeping the signing secret on one private, hardened auth server (or cluster) also allows smart things like automated key rotation. 2. 100%. There's at least one right way to do JWT, but more ways to do JWT wrong. 3. JWT et al provide a fine starting point, I don't see a reason to start from scratch. I'm not tied to the JWT spec, but I'm quite happy with what I've been able to accomplish using a careful implementation in my AuthN server: https://github.com/keratin/authn https://github.com/keratin/authn

tracker1 10y ago
Agreed... my first two experiences with JWT were creating my own implementation... in my case, the allowed public keys had to come via https from a specific server in the domain, even without PKI using shared key... I had hard coded the algorithm used for the signature. This could just as easily be filters on a library though, it's just my first experience didn't have a valid library, so I had to composite one (did use existing crypto library though). JWT is a perfectly valid structure, even if the spec is more flexible than it should be. By that matter, https also has historically supported algorithms and protocols later broken. Nobody is suggesting we stop use HTTPS, only that we limit acceptable protocol and algorithms supported.
- tptacek 10y ago
  No, almost everybody in the field laments SSL and TLS. It's probably too late at this point --- and has been for well over a decade --- to get to something better than TLS, and so TLS 1.3 is what we're stuck with. But that is demonstrably not the case with JWT. We don't have to convince all the browser vendor to upgrade out of JWT in lockstep. Avoiding another 20 years of hair-on-fire crypto vulnerabilities seems reason enough to lobby against that spec.
  - tracker1 10y ago