A Child’s Garden of Inter-Service Authentication Schemes

Post by pvg » Wed, Jun 13, 2018, 11:57 AM UTC

sytringy05 wrote: post #27

pvg wrote: post #26

Earlier quoted context omitted.

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 l…

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 authen…

Post by jameshart » Wed, Jun 13, 2018, 12:18 PM UTC

bullen wrote: post #30

jameshart wrote: post #29

Earlier quoted context omitted.

Hashing or HMACing? How is ‘single use’ of the salt enforced?

Just hash = hash(secret + salt) and the server enforces the single use by generating and sending one for each authentication, so you need double handshake: client ----- server req salt -> gen salt hash sec. send hash -> remove salt all good? <- verify hash

Post by evancordell » Wed, Jun 13, 2018, 12:43 PM UTC

sarcasmic wrote: post #11

If you're like me and are wondering what Macaroons are, some searching revealed to me that this is the 2014 paper [1] that introduced them to the public. It's a nested, chained HMAC construction that's useful for delegation, and here's a library and some code examples [2] that one can play with to get a feel for what they do and how. No wonder it's not well known: it hasn't been picked up by the blog treadmill where…

Post by lvh » Wed, Jun 13, 2018, 12:47 PM UTC

dward wrote: post #15

jameshart wrote: post #4

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 get…

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).

Post by jameshart » Wed, Jun 13, 2018, 12:56 PM UTC

tptacek wrote: post #14

jameshart wrote: post #10

Earlier quoted context omitted.

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 ne…

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.