7 ms·

We use public-key JWTs so that the verifying servers do not have a copy of the secret key, just the authorisation server's public key. That prevents a compromi

We use public-key JWTs so that the verifying servers do not have a copy of the secret key, just the authorisation server's public key. That prevents a compromise of the verifying servers from also compromising the entire system (yes, a compromised verifying server can be made to do anything it's allowed to do — but that's still less than everything).

davars 9y ago
Also, issuing servers and verifying servers don't even need to be part of the same organization, allowing you to outsource credential management (see Auth0, Firebase Authentication).
- lvh 9y ago
  You can do that fine with secret-key cryptography too.
  - davars 9y ago
    By downloading a shared key over TLS rather than the provider's public key? No difference from the perspective of the token consumer. From the perspective of they token generator, it means rotating per-tenant keys rather than a single keypair.
    - lvh 9y ago
      I addressed this elsewhere (https://news.ycombinator.com/item?id=16072690 https://news.ycombinator.com/item?id=16072690) but to quickly recap: that's not the hard problem, and hardened SAML IdPs that have the option of exploiting this turn out to have per-tenant keys anyway so that they can get cryptographic binding instead of counting on audience restrictions being checked. Additionally, your TLS terminating stack is much better hardened than median in-app crypto code.
orf 9y ago
We do exactly the same, it's a great feature to have in JWT's.
tptacek 9y ago
This is the logic people use when they encrypt cookies to public keys. I've never tested a system with public key encrypted cookies that wasn't broken. As a general rule of thumb: public key is what you use when you have no other choice. PAST mitigates the risk somewhat by hardcoding a public key system into its version. But I'm still recoiling from the kind of first-principles mixing of systems security and cryptography that happens when people find new reasons to deploy public key primitives. Note that one of the first crypto bugs in JWT stemmed from how it used curve public key crypto.
- grogenaut 9y ago
  Your points sound very interesting but don't provide any details. Could you provide more details, I'm interested in learning about this. For instance is there a good resource you use on what are good alternatives when you think you need to use PKI when in fact there are better alternatives? Is there a good resource on how to use JWT correctly that you trust? (Edited-tone, was a bit more aggressive but was pointing out the opportunity to educate instead of just say things are bad).
  - tptacek 9y ago
    I'm pretty comfortable with the makeup of the subset of HN readers that take me seriously and/or understand where I'm coming from, and so I'm going to avoid litigating with strangers on this one.
    - grogenaut 9y ago
      I'd still love to know the details.
      - WhitneyLand 9y ago
        My speculative interpretation (which Thomas may disavow completely) is that not that eadmund was doing something technically broken, as much as adding complexity, and risk of mistakes somewhere along the chain, without benefits to justify doing so. If you listen closely, some security wisdom could applies to a lot of specialties. For ex this quote is about authenticated encryption, but it's not really bad advice if you change the subject from encryption, to rolling your own web server: "Authenticated encryption is something you should use as a complete package, implemented as a single unit by a well-reputed open source cryptographic library and not assembled piecemeal by people who do not specialize in cryptography." So what's the difference then? The stakes are higher. Serve the wrong web page, you'll be working on a bug. Be careless with security primitives, you could make a fortune 500 stock price go down, or make your CEO have to issue a press release, which tends to not to reflect well on your performance review. In this light, "finding new reasons" I would infer to mean deviating from established best practices in any way without a damn good reason, even then without that reason being challenged and vetted. All of the creativity in security should be in the research. For production implementations I don't want any creativity. Ideally, I'd want prod to be the opposite of research: Conservative and uncreative, struggling to stay awake because it's so boring and uneventful.

davars 9y ago

Also, issuing servers and verifying servers don't even need to be part of the same organization, allowing you to outsource credential management (see Auth0, Firebase Authentication).

lvh 9y ago
You can do that fine with secret-key cryptography too.
- davars 9y ago
  By downloading a shared key over TLS rather than the provider's public key? No difference from the perspective of the token consumer. From the perspective of they token generator, it means rotating per-tenant keys rather than a single keypair.
  - lvh 9y ago
    I addressed this elsewhere (https://news.ycombinator.com/item?id=16072690 https://news.ycombinator.com/item?id=16072690) but to quickly recap: that's not the hard problem, and hardened SAML IdPs that have the option of exploiting this turn out to have per-tenant keys anyway so that they can get cryptographic binding instead of counting on audience restrictions being checked. Additionally, your TLS terminating stack is much better hardened than median in-app crypto code.

orf 9y ago

We do exactly the same, it's a great feature to have in JWT's.

tptacek 9y ago

This is the logic people use when they encrypt cookies to public keys. I've never tested a system with public key encrypted cookies that wasn't broken. As a general rule of thumb: public key is what you use when you have no other choice. PAST mitigates the risk somewhat by hardcoding a public key system into its version. But I'm still recoiling from the kind of first-principles mixing of systems security and cryptography that happens when people find new reasons to deploy public key primitives. Note that one of the first crypto bugs in JWT stemmed from how it used curve public key crypto.

grogenaut 9y ago
Your points sound very interesting but don't provide any details. Could you provide more details, I'm interested in learning about this. For instance is there a good resource you use on what are good alternatives when you think you need to use PKI when in fact there are better alternatives? Is there a good resource on how to use JWT correctly that you trust? (Edited-tone, was a bit more aggressive but was pointing out the opportunity to educate instead of just say things are bad).
- tptacek 9y ago
  I'm pretty comfortable with the makeup of the subset of HN readers that take me seriously and/or understand where I'm coming from, and so I'm going to avoid litigating with strangers on this one.
  - grogenaut 9y ago
    I'd still love to know the details.
    - WhitneyLand 9y ago
      My speculative interpretation (which Thomas may disavow completely) is that not that eadmund was doing something technically broken, as much as adding complexity, and risk of mistakes somewhere along the chain, without benefits to justify doing so. If you listen closely, some security wisdom could applies to a lot of specialties. For ex this quote is about authenticated encryption, but it's not really bad advice if you change the subject from encryption, to rolling your own web server: "Authenticated encryption is something you should use as a complete package, implemented as a single unit by a well-reputed open source cryptographic library and not assembled piecemeal by people who do not specialize in cryptography." So what's the difference then? The stakes are higher. Serve the wrong web page, you'll be working on a bug. Be careless with security primitives, you could make a fortune 500 stock price go down, or make your CEO have to issue a press release, which tends to not to reflect well on your performance review. In this light, "finding new reasons" I would infer to mean deviating from established best practices in any way without a damn good reason, even then without that reason being challenged and vetted. All of the creativity in security should be in the research. For production implementations I don't want any creativity. Ideally, I'd want prod to be the opposite of research: Conservative and uncreative, struggling to stay awake because it's so boring and uneventful.