Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Child’s Garden of Inter-Service Authentication Schemes

latacora.singles

Post reply on HN
Print view View original

41–50 of 54 posts

Re: A Child’s Garden of Inter-Service Authentication Schemes

#41

Post by lvh »

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…

Re: JWT; sure, but it’s a multifaceted problem that’s more than one blog post. We’ll get there. Unfortunately, we’ve been saying most of that for years now, just because it’s not easily accessible in one place (a valid criticism!) doesn’t mean I’m not exhausted talking about it :)

Re: A Child’s Garden of Inter-Service Authentication Schemes

#42

Post by [deleted] »

jameshart wrote: post #10
lvh wrote: post #8

Earlier quoted context omitted.

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[*]…

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…

[deleted]

Re: A Child’s Garden of Inter-Service Authentication Schemes

#43

Post by lvh »

pvg wrote: post #31
sytringy05 wrote: post #27

Earlier quoted context omitted.

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…

Huh, yeah that's interesting, thanks. I'm obviously way behind the state of the art in JWT-hating.

FWIW, this matches my experience. Large new enterprise systems have JWT all over the place.

My first pass counterargument to this is: great! You also have FAANG’s security budget and know how to find and resolve bugs like the FB OAuth2.0 tokens being replayable from 1 relying party to another, right? No? Oh.

The general subtext being: that’s nice but you know nothing of their rationale, underlying work that went into securing it, etc; so if you’re picking up a token metaformat without the massive work behind it, you’re just cargo culting.

Re: A Child’s Garden of Inter-Service Authentication Schemes

#44

Post by lvh »

HurrdurrHodor wrote: post #32

I am somewhat surprised by the statements about asymmetric crypto algorithms. Given a good library they don't seem more error prone and given many common use-cases they are not significantly slower.

Securealpolitik: saying there are safe asymmetric primitives doesn’t mean that’s what’s actually deployed. As long as the spec says is P256 ECDSA it’s a pretty reasonable assumption someone is going to screw up nonce handling.

(Incidentally ECDSA really is that much slower, but I appreciate that could be seen as cherry picking because ECDSA is slow even for an asymmetric algorithm.)

I don’t think the argument we’re trying to make is that asymmetric crypto definitionally can’t work. I’m pretty happy TLS exists. Just skeptical that you want to build your s2s auth on it.

Re: A Child’s Garden of Inter-Service Authentication Schemes

#45

Post by lvh »

evancordell wrote: post #38
dward wrote: post #15

Earlier quoted context omitted.

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

I implemented publicly-verifiable macaroons as a PoC and found them reasonably ergonomic: https://github.com/ecordell/watchstander (docs are sparse, I wrote an accompanying doc that might help: https://docs.google.com/document/d/1AU9bwpMYlnWBlwSIiwNyse0N... ) The basic idea is what you described: append only asymmetrically verifiable signatures. As with most things Macaroons, the harder part is developing a caveat la…

I think there are a few weird incompatibilities between libraries that are likely to bite you unless you have 1 library you use, but generally speaking: yes, figuring out how to structure your claims is the hard part. Most claims are really quite simple, which is why I’m bullish on most tiny startups just sticking a random token in a database and calling it a day.

Re: A Child’s Garden of Inter-Service Authentication Schemes

#46

Post by bullen »

jameshart wrote: post #33
bullen wrote: post #30

Earlier quoted context omitted.

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

How does the server verify that the salt it receives in the second request is the same salt it generated in the first response? Does the server have to retain state? Also you should maybe read https://benlog.com/2008/06/19/dont-hash-secrets/

Servers are stateful.

Re: A Child’s Garden of Inter-Service Authentication Schemes

#47

Post by pvg »

lvh wrote: post #43
pvg wrote: post #31

Earlier quoted context omitted.

Huh, yeah that's interesting, thanks. I'm obviously way behind the state of the art in JWT-hating.

FWIW, this matches my experience. Large new enterprise systems have JWT all over the place. My first pass counterargument to this is: great! You also have FAANG’s security budget and know how to find and resolve bugs like the FB OAuth2.0 tokens being replayable from 1 relying party to another, right? No? Oh. The general subtext being: that’s nice but you know nothing of their rationale, underlying work that went into…

Yep, that makes sense. I'm having a bit of a 'oh, so that's why' moment while also feeling a little envious of a subfield where 'the inadequate size of your budget' is a viable starting point for a constructive conversation with a client.

Re: A Child’s Garden of Inter-Service Authentication Schemes

#48

Post by bullen »

jessaustin wrote: post #34
bullen wrote: post #30

Earlier quoted context omitted.

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

Which hash are you using? All this would be for naught if it's one of the many susceptible to length extension attacks; e.g. SHA2. This is the reason everyone uses HMAC now.

The salt is not attacker-controlled.

Re: A Child’s Garden of Inter-Service Authentication Schemes

#49

Post by dward »

lvh wrote: post #37
dward wrote: post #15

Earlier quoted context omitted.

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

Are you thinking Vanadium or some other spec?

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

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.

Re: A Child’s Garden of Inter-Service Authentication Schemes

#50

Post by lvh »

pvg wrote: post #47
lvh wrote: post #43

Earlier quoted context omitted.

FWIW, this matches my experience. Large new enterprise systems have JWT all over the place. My first pass counterargument to this is: great! You also have FAANG’s security budget and know how to find and resolve bugs like the FB OAuth2.0 tokens being replayable from 1 relying party to another, right? No? Oh. The general subtext being: that’s nice but you know nothing of their rationale, underlying work that went into…

Yep, that makes sense. I'm having a bit of a 'oh, so that's why' moment while also feeling a little envious of a subfield where 'the inadequate size of your budget' is a viable starting point for a constructive conversation with a client.

That's an argument from/with random people on the Internet, not clients. The nice thing about being around clients for a long time is that you build a working relationship with them based on mutual trust and respect.

That said, adequately informing clients of risk and dissuading them from nightmare projects they don't realize are nightmare projects yet is doing your clients a service. Sometimes that means advising them to avoid a feature. Sometimes it means implementing something slightly differently. Most of the time it's not even a trade-off. People use JWTs with just user ids in them, but not necessarily for any particular technical/philosophical reason that you have to address first :-)

Post reply on HN