7 ms·

Is this finally the more expansive statement from tptacek than just "Don't use JWTs" that I've been waiting for? Still feels like we're waiting for another sho

Is this finally the more expansive statement from tptacek than just "Don't use JWTs" that I've been waiting for? Still feels like we're waiting for another shoe to drop in this space - maybe it really is Macaroons? But since container-driven microservice orchestration is ultimately destined to recapitulate the whole of CORBA and DCOM and therefore probably kerberos and every flavor of PKI ever attempted before it gets blown up and replaced with something leaner and simpler and based on shared secrets again, I don't hold out much hope.

lvh 8y ago
I’m not ‘tptacek but I am a Latacora principal. It is partially. The problem with the question of what you should use instead of JWT is that it presupposes a usually-wrong assumption that you actually want something of the same shape as JWT, which is usually not true. JWT is a bad answer to the wrong problem: addressing the bad answer part doesn’t address the wrong problem part. To riff off of jackhammer questions[*], just because chainsaws like PASETO exist and a chainsaw is more effective than a jackhammer at a specific task, doesn’t mean you really wanted a chainsaw. We will be following up :) [jackhammers]:
- jameshart 8y ago
  Apologies for misattribution :) So yes, this is precisely the problem with sending the message 'JWT is bad' when what you really want to send is 'bearer tokens are bad (and JWT is a badly designed bearer token)'. I am reminded of the situation a few years ago where the message 'stop hashing/salting passwords with SHA1' got widely interpreted as 'Okay, I'll salt and hash with SHA256', when the real message that was needed was to use bcrypt. But this time I'm not sure there's a bcrypt, yet.
  - tptacek 8y ago
    That argument doesn't work, because JWT isn't just a "bearer token". It's also potentially an asymmetric token, or any other mechanism someone tries to shoehorn into it next week. That's one of the problems with metaformats. This post isn't a comprehensive argument against JWTs and isn't intended to be. We can't have the conversation about JWT in earnest until we understand the problem domain.
    - pvg 8y ago
      We can't have the conversation about JWT in earnest until we understand the problem domain. That you're taking it from there is really interesting. Are you finding a lot of JWT use when there's also some S2S auth setup?
      - sytringy05 8y ago
        Everybody is doing it (at least where I'm from). There's good framework/vendor support for OAuth 2 and JWT breaks the nexus between the services and the magic auth server that must be called on each and every request. Even with the horrors of the implementation ({"alg": "none"}) It's a risk that many organisations are willing to take.
        pvg 8y ago
        Right, but it sounds (if I'm understanding you right) like you're talking about JWT-and-things-as-a-way-for-your-services-to-talk-to-each-other-through-the-client. This is roughly analogous to Ruby cookies - save yourself a database read through the power of maths. But tptacek seems to be saying 'I want you to understand all this S2S stuff before I can begin to rant at you about JWT'. That's a bit different and I'd like to get the rest of this newsletter.
        sytringy05 8y ago
        No, I meant in the context of server to server comms, as well as end user authn/authz. I would say that jwt is becoming the standard for s2s. I’ve personally worked with a dozen or so corporate APIs that use it and basically all the Microsoft Azure / 365 services are secured with jwt. I’m intrigued by macaroon because as tptacek points out JWT is easy to get wrong, you’ve got to deserialize json before you can authenticate the request and it’s also tempting to stuff all manner of things into the token claims.
        pvg 8y ago
        Huh, yeah that's interesting, thanks. I'm obviously way behind the state of the art in JWT-hating.
  - deleted 8y ago
    [deleted]
- lvh 8y ago
  I flubbed the link to jackhammer questions last night: http://bash.org/?866112 http://bash.org/?866112
dward 8y ago
The published asymmetric macaroon constructions were pretty gross last time I looked. We were missing a practical asymmetrically verifiable append only signature. This deficiency rules macaroons out of numerous use cases (namely where the relying party is separate from and untrusted by the issuing party).
- ithkuil 8y ago
  I found this part to be one of the most common gotchas of macaroons. As often happens when everybody is "holding it wrong", users are not probably the only ones to be blamed. That said, macaroons (from what I understood) are meant to be a token that is only verifiable by the issuer. Third party caveats allow more complex scenarios, but they necessarily involve actual s2s communication to set up (as opposed to the "verification at a distance" allowed by pure asymmetrical crypto) For example: service A issues a macaroon to service B. Now imagine service B needs to talk to service C, which in turns needs to ensure that B can perform some action on service A. If C could verify A's public key signature, we could stop here. With macaroons, C needs to issue a macaroon to B, with a third party caveats that requires B to obtain a "discharge macaroon" from A. When B later performs the request on C, it brings both macaroons (the one issued by C with the 3rd party caveat, and the one issued by A, that proves that the caveat is discharged). C can verify such a macaroon. In particular it can cheaply verify that A is the source of the 3rd party verification.
- lvh 8y ago
  Are you thinking Vanadium or some other spec?
  - dward 8y ago
    Albeit this was years ago but I was referring to the construction linked from the original paper proposed in: https://cs.nyu.edu/media/publications/TR2013-962.pdf https://cs.nyu.edu/media/publications/TR2013-962.pdf It’s pretty unweildy compared to HMAC construction because: * each caveat addition requires local generation of a new asymmetric key pair * the size of the macaroon grows linearly with the number of caveats. Each new caveat concatenates two asymmetric signatures to the append only signature. Each new caveat adds a public key to the macaroon ID. * it requires a finalize step for security, meaning the final macaroon extender needs to know it’s the final extender. It sounded rather impractical but I wouldn’t be surprised if improvements have been made since then.

lvh 8y ago

I’m not ‘tptacek but I am a Latacora principal. It is partially. The problem with the question of what you should use instead of JWT is that it presupposes a usually-wrong assumption that you actually want something of the same shape as JWT, which is usually not true. JWT is a bad answer to the wrong problem: addressing the bad answer part doesn’t address the wrong problem part. To riff off of jackhammer questions[*], just because chainsaws like PASETO exist and a chainsaw is more effective than a jackhammer at a specific task, doesn’t mean you really wanted a chainsaw. We will be following up :) [jackhammers]:

jameshart 8y ago
Apologies for misattribution :) So yes, this is precisely the problem with sending the message 'JWT is bad' when what you really want to send is 'bearer tokens are bad (and JWT is a badly designed bearer token)'. I am reminded of the situation a few years ago where the message 'stop hashing/salting passwords with SHA1' got widely interpreted as 'Okay, I'll salt and hash with SHA256', when the real message that was needed was to use bcrypt. But this time I'm not sure there's a bcrypt, yet.
- tptacek 8y ago
  That argument doesn't work, because JWT isn't just a "bearer token". It's also potentially an asymmetric token, or any other mechanism someone tries to shoehorn into it next week. That's one of the problems with metaformats. This post isn't a comprehensive argument against JWTs and isn't intended to be. We can't have the conversation about JWT in earnest until we understand the problem domain.
  - pvg 8y ago
    We can't have the conversation about JWT in earnest until we understand the problem domain. That you're taking it from there is really interesting. Are you finding a lot of JWT use when there's also some S2S auth setup?
    - sytringy05 8y ago
      Everybody is doing it (at least where I'm from). There's good framework/vendor support for OAuth 2 and JWT breaks the nexus between the services and the magic auth server that must be called on each and every request. Even with the horrors of the implementation ({"alg": "none"}) It's a risk that many organisations are willing to take.
      - pvg 8y ago
        Right, but it sounds (if I'm understanding you right) like you're talking about JWT-and-things-as-a-way-for-your-services-to-talk-to-each-other-through-the-client. This is roughly analogous to Ruby cookies - save yourself a database read through the power of maths. But tptacek seems to be saying 'I want you to understand all this S2S stuff before I can begin to rant at you about JWT'. That's a bit different and I'd like to get the rest of this newsletter.
        sytringy05 8y ago
        No, I meant in the context of server to server comms, as well as end user authn/authz. I would say that jwt is becoming the standard for s2s. I’ve personally worked with a dozen or so corporate APIs that use it and basically all the Microsoft Azure / 365 services are secured with jwt. I’m intrigued by macaroon because as tptacek points out JWT is easy to get wrong, you’ve got to deserialize json before you can authenticate the request and it’s also tempting to stuff all manner of things into the token claims.
        pvg 8y ago
        Huh, yeah that's interesting, thanks. I'm obviously way behind the state of the art in JWT-hating.
- deleted 8y ago
  [deleted]
lvh 8y ago
I flubbed the link to jackhammer questions last night: http://bash.org/?866112 http://bash.org/?866112

dward 8y ago

The published asymmetric macaroon constructions were pretty gross last time I looked. We were missing a practical asymmetrically verifiable append only signature. This deficiency rules macaroons out of numerous use cases (namely where the relying party is separate from and untrusted by the issuing party).

ithkuil 8y ago
I found this part to be one of the most common gotchas of macaroons. As often happens when everybody is "holding it wrong", users are not probably the only ones to be blamed. That said, macaroons (from what I understood) are meant to be a token that is only verifiable by the issuer. Third party caveats allow more complex scenarios, but they necessarily involve actual s2s communication to set up (as opposed to the "verification at a distance" allowed by pure asymmetrical crypto) For example: service A issues a macaroon to service B. Now imagine service B needs to talk to service C, which in turns needs to ensure that B can perform some action on service A. If C could verify A's public key signature, we could stop here. With macaroons, C needs to issue a macaroon to B, with a third party caveats that requires B to obtain a "discharge macaroon" from A. When B later performs the request on C, it brings both macaroons (the one issued by C with the 3rd party caveat, and the one issued by A, that proves that the caveat is discharged). C can verify such a macaroon. In particular it can cheaply verify that A is the source of the 3rd party verification.
lvh 8y ago
Are you thinking Vanadium or some other spec?
- dward 8y ago
  Albeit this was years ago but I was referring to the construction linked from the original paper proposed in: https://cs.nyu.edu/media/publications/TR2013-962.pdf https://cs.nyu.edu/media/publications/TR2013-962.pdf It’s pretty unweildy compared to HMAC construction because: * each caveat addition requires local generation of a new asymmetric key pair * the size of the macaroon grows linearly with the number of caveats. Each new caveat concatenates two asymmetric signatures to the append only signature. Each new caveat adds a public key to the macaroon ID. * it requires a finalize step for security, meaning the final macaroon extender needs to know it’s the final extender. It sounded rather impractical but I wouldn’t be surprised if improvements have been made since then.