4 ms·

https://news.ycombinator.com/item?id=21785888 https://news.ycombinator.com/item?id=21785888 tptacek Credential attenuation in Macaroons is cryptographic

by teyc 7y ago

https://news.ycombinator.com/item?id=21785888 https://news.ycombinator.com/item?id=21785888 tptacek Credential attenuation in Macaroons is cryptographic; it's in how the tokens are constructed. I don't see the opportunity for a DoS (that didn't exist without attenuation already). Macaroons are a really lovely, tight, purpose-built design that happens to capture a lot of things you want out of an API token, including some things that JWTs don't express naturally despite their kitchen-sink design. JWT is more popular because there are libraries for it in every language, and people don't think of tokens as a cryptographic design (or nobody would be using JWT!), they think of them as a library ecosystem. JWT is definitely the stronger library ecosystem! This is also why I probably wouldn't ever bother recommending PASETO. If you're sophisticated enough to evaluate token formats based on their intrinsic design, then you should implement Macaroons if possible (it's almost always possible). If you're not, then you're going to use JWT.

twic 7y ago
I'd never heard of macaroons. Here is a website: http://macaroons.io/ http://macaroons.io/ I note that the logo depicts macarons [1], rather than macaroons [2]. A parent comment also mentions PASETO: https://paseto.io/ https://paseto.io/ Sadly, a paseto does not appear to be any kind of biscuit. The PASETO site links to this searing indictment of JWTs and related things: https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba... I am far from qualified to evaluate any of these! [1] https://en.wikipedia.org/wiki/Macaron https://en.wikipedia.org/wiki/Macaron [2] https://en.wikipedia.org/wiki/Macaroon https://en.wikipedia.org/wiki/Macaroon
- chrisseaton 7y ago
  Some locales do call the things in the icons macaroons.
- saagarjha 7y ago
  Off topic: it gives me undue vexation that there are two dessert items with names so similar to each other that everyone keeps confusing them. Can we just all agree to come up with a new name for one of them?
  - namewasmypw 7y ago
    They're from different languages...
  - twic 7y ago
    To be fair, there is a similar situation with "cookie", which means any kind of small, flat, compact, unleavened flour-based sweet baked item in the USA, but more specifically a particular soft kind in the UK. And conversely, "biscuit", which has the former meaning in the UK and means some sort of weird scone in the USA.
- arnarbi 7y ago
  > I note that the logo depicts macarons [1], rather than macaroons [2]. Partly (largely?) my fault. When we wrote the Macaroons paper, I was simply not aware that Americans use the French word when referring to the French variety of macaroons. I think pedantry in auth should be celebrated.
- dwaite 7y ago
  I hear macaroons come up fairly often, but they suffer from being only described by a Google research paper, without a standard or other sufficient formal specification. My understanding is that compatibility across implementations is lacking. PASETO is by Paragon, the authors of said searing indictment. IMHO their argument really comes down to a difference in opinion in how cryptography should be supplied to developers. TLS and JWT standards allow for a wide variety of cryptographic algorithms, and implementations may provide various ways to negotiate that set of algorithms, such as whitelisted set. This provides for migration over time from legacy systems to new algorithms, but creates a risk that the library author will have a security issue in their implementation of the standard, or that the application developer will misconfigure said implementation. The alternative strategy is something like NaCL/libsodium http://nacl.cr.yp.to http://nacl.cr.yp.to, where experts standardize on single packages of algorithms (or extremely limited set, such as one standard and one legacy) to implement specific cryptographic primitives. The problem usually quoted here is one of compatibility, migration, and experimentation. There are often no provisions for older systems which cannot handle one of the profiles involved, or primitives for managing non-standard cryptographic sets. Many of these specifications also dictate removal of an old algorithm set to add a new one - making the specification only really valid in lock-step upgraded systems.
Ficirdly 7y ago
Just not Macaroons again :( Macaroons have many small edge cases that'll bite you when you try to use them in practice: - there is no spec and all people re-implement the de-facto standard. If you read the whitepaper it's not what's in use. - the de-facto implementation is full of holes, e.g. time is expressed without timezone so it's not clear if it's UTC or not. - the implementation requires custom parser for custom binary format but the caveats in wild use (remember: there are no standard ones) still use text so it just avoids the potential benefits of encoding dates and numbers in binary. - the highly hyped third-party macaroons are barely supported in implementations in the wild - only one level is allowed and it's not specified anywhere. - if we're talking about third-party macaroons there is another layer of problems: no standard for caveats means your third-party service needs to be closely coupled with your own. - immature implementations, I'll just leave this here: https://github.com/nitram509/macaroons.js/blob/master/src/main/ts/CryptoTools.ts#L61-L63 https://github.com/nitram509/macaroons.js/blob/master/src/ma... JWTs have many problems but compared to Macaroons it's just JSON and base64. This is available in all programming languages with no additional cost. JWTs also have actual spec that implementations can agree on. Macaroons promise you extreme power but doesn't deliver. Several of Macaroons issues could be resolved with some effort (e.g. standarization) others - like resolving cycles in third-party caveats are IMO design flaws deeply embedded in the format. For more info from people deploying Macaroons in the wild see https://www.youtube.com/watch?v=MZFv62qz8RU https://www.youtube.com/watch?v=MZFv62qz8RU As for tptacek's recommendation this only serves as a reminder that even if a highly respected internet figure recommends you something you still need to do your own homework instead of blindly following.
- oefrha 7y ago
  > - immature implementations, I'll just leave this here: https://github.com/nitram509/macaroons.js/blob/master/src/main/ts/CryptoTools.ts#L61-L63 https://github.com/nitram509/macaroons.js/blob/master/src/ma... Wow. In case the master changes, here’s the highlighted code: /* XXX get some random bytes instead */ var enc_plaintext:Buffer = new Buffer(MacaroonsConstants.MACAROON_HASH_BYTES); enc_plaintext.fill(0); This library’s README should have an all cap “toy project, don’t use” up top.

by teyc 7y ago

twic 7y ago

I'd never heard of macaroons. Here is a website: http://macaroons.io/ http://macaroons.io/ I note that the logo depicts macarons [1], rather than macaroons [2]. A parent comment also mentions PASETO: https://paseto.io/ https://paseto.io/ Sadly, a paseto does not appear to be any kind of biscuit. The PASETO site links to this searing indictment of JWTs and related things: https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba... I am far from qualified to evaluate any of these! [1] https://en.wikipedia.org/wiki/Macaron https://en.wikipedia.org/wiki/Macaron [2] https://en.wikipedia.org/wiki/Macaroon https://en.wikipedia.org/wiki/Macaroon

chrisseaton 7y ago
Some locales do call the things in the icons macaroons.
saagarjha 7y ago
Off topic: it gives me undue vexation that there are two dessert items with names so similar to each other that everyone keeps confusing them. Can we just all agree to come up with a new name for one of them?
- namewasmypw 7y ago
  They're from different languages...
- twic 7y ago
  To be fair, there is a similar situation with "cookie", which means any kind of small, flat, compact, unleavened flour-based sweet baked item in the USA, but more specifically a particular soft kind in the UK. And conversely, "biscuit", which has the former meaning in the UK and means some sort of weird scone in the USA.
arnarbi 7y ago
> I note that the logo depicts macarons [1], rather than macaroons [2]. Partly (largely?) my fault. When we wrote the Macaroons paper, I was simply not aware that Americans use the French word when referring to the French variety of macaroons. I think pedantry in auth should be celebrated.
dwaite 7y ago
I hear macaroons come up fairly often, but they suffer from being only described by a Google research paper, without a standard or other sufficient formal specification. My understanding is that compatibility across implementations is lacking. PASETO is by Paragon, the authors of said searing indictment. IMHO their argument really comes down to a difference in opinion in how cryptography should be supplied to developers. TLS and JWT standards allow for a wide variety of cryptographic algorithms, and implementations may provide various ways to negotiate that set of algorithms, such as whitelisted set. This provides for migration over time from legacy systems to new algorithms, but creates a risk that the library author will have a security issue in their implementation of the standard, or that the application developer will misconfigure said implementation. The alternative strategy is something like NaCL/libsodium http://nacl.cr.yp.to http://nacl.cr.yp.to, where experts standardize on single packages of algorithms (or extremely limited set, such as one standard and one legacy) to implement specific cryptographic primitives. The problem usually quoted here is one of compatibility, migration, and experimentation. There are often no provisions for older systems which cannot handle one of the profiles involved, or primitives for managing non-standard cryptographic sets. Many of these specifications also dictate removal of an old algorithm set to add a new one - making the specification only really valid in lock-step upgraded systems.

Ficirdly 7y ago

Just not Macaroons again :( Macaroons have many small edge cases that'll bite you when you try to use them in practice: - there is no spec and all people re-implement the de-facto standard. If you read the whitepaper it's not what's in use. - the de-facto implementation is full of holes, e.g. time is expressed without timezone so it's not clear if it's UTC or not. - the implementation requires custom parser for custom binary format but the caveats in wild use (remember: there are no standard ones) still use text so it just avoids the potential benefits of encoding dates and numbers in binary. - the highly hyped third-party macaroons are barely supported in implementations in the wild - only one level is allowed and it's not specified anywhere. - if we're talking about third-party macaroons there is another layer of problems: no standard for caveats means your third-party service needs to be closely coupled with your own. - immature implementations, I'll just leave this here: https://github.com/nitram509/macaroons.js/blob/master/src/main/ts/CryptoTools.ts#L61-L63 https://github.com/nitram509/macaroons.js/blob/master/src/ma... JWTs have many problems but compared to Macaroons it's just JSON and base64. This is available in all programming languages with no additional cost. JWTs also have actual spec that implementations can agree on. Macaroons promise you extreme power but doesn't deliver. Several of Macaroons issues could be resolved with some effort (e.g. standarization) others - like resolving cycles in third-party caveats are IMO design flaws deeply embedded in the format. For more info from people deploying Macaroons in the wild see https://www.youtube.com/watch?v=MZFv62qz8RU https://www.youtube.com/watch?v=MZFv62qz8RU As for tptacek's recommendation this only serves as a reminder that even if a highly respected internet figure recommends you something you still need to do your own homework instead of blindly following.

oefrha 7y ago
> - immature implementations, I'll just leave this here: https://github.com/nitram509/macaroons.js/blob/master/src/main/ts/CryptoTools.ts#L61-L63 https://github.com/nitram509/macaroons.js/blob/master/src/ma... Wow. In case the master changes, here’s the highlighted code: /* XXX get some random bytes instead */ var enc_plaintext:Buffer = new Buffer(MacaroonsConstants.MACAROON_HASH_BYTES); enc_plaintext.fill(0); This library’s README should have an all cap “toy project, don’t use” up top.