[HN Gopher] Macaroons Escalated Quickly
___________________________________________________________________
Macaroons Escalated Quickly
Author : mkeeter
Score : 186 points
Date : 2024-01-31 14:39 UTC (8 hours ago)
(HTM) web link (fly.io)
(TXT) w3m dump (fly.io)
| ssl232 wrote:
| TIL macarons [1] are also known as macaroons [2]. Where I'm from,
| macaroons are dense, sweet coconut treats and the French sweets
| are known as macarons. But from the Wikipedia article I see
| macaroons mean many different things to many different people.
|
| [1] https://en.wikipedia.org/wiki/Macaron
|
| [2] https://en.wikipedia.org/wiki/Macaroon
| cmcconomy wrote:
| it messed with my head to hear that the english world
| interprets an "entree" as a main course
| ssl232 wrote:
| American English, but not British. Dinner here is a starter,
| main course and dessert. "Entree" messes with my head as
| well, since it very much sounds like a starter.
| bdsa wrote:
| It's French for starter, even
| KineticLensman wrote:
| > Dinner here is a starter, main course and dessert.
|
| Yep. Check out the online menus in English restaurants and
| pubs. 'Mains' is the typical term used.
| wiredfool wrote:
| It's also the electrical supply. What a country.
| ssl232 wrote:
| And the water supply. And the central building on farms
| (in Scotland, at least). It's a silly country.
| dboreham wrote:
| Don't even think about "a la mode" then.
| aidenn0 wrote:
| I speak French, not Italian!
| gonzus wrote:
| Switzerland has the similar Luxemburgerli, which my Swiss
| friends who reside there (as opposed to me, a Swiss person who
| lives somewhere else) swear is NOT the same as a macaron... I
| have never understood the purported differences.
| demondemidi wrote:
| I was just about to complain. Thanks for nipping it in the bud!
| ISV_Damocles wrote:
| This feels relevant to the conversation:
| https://twitter.com/BigSpiderBack/status/864309383106240512/...
| enriquto wrote:
| > TIL macarons [1] are also known as macaroons [2]
|
| Not to forget macarrons! Where I'm from, macarrons [3] is a
| kind of pasta (penne).
|
| [3] https://ca.wikipedia.org/wiki/Macarrons
| madcaptenor wrote:
| In English "macaroni" is a kind of pasta. (I'm being
| deliberately vague because which pasta it is seems to vary.)
| sph wrote:
| And the original name for that type of pasta in Italian is
| "maccheroni" (which are straight tubes, unlike the ones
| used abroad for "mac and cheese")
| pasc1878 wrote:
| Or in English macaroni https://en.wikipedia.org/wiki/Macaroni
| CoastalCoder wrote:
| > Where I'm from, macaroons are dense, sweet coconut treats and
| the French sweets are known as macarons.
|
| Same for me (New England, USA).
|
| Both are delicious, but in my dialect they are not the same
| thing.
| Nition wrote:
| Oh funny, I actually came to this comment thread to point out
| that they'd accidentally used a picture of macarons instead of
| macaroons in the blog. But I guess not necessarily!
| xyzzy_plugh wrote:
| > Until now! I dragged Fly.io into implementing them. Suckers!
|
| Let's be real: they knew you would do this eventually. It was
| inevitable.
| asplake wrote:
| Typo/bug: pretty sure variable 'oldTag' should be 'oldTail'
| tptacek wrote:
| Thanks! They're basically interchangeable --- HMAC produces a
| "MAC tag", and in the context of the Macaroon protocol the last
| visible tag is called a "tail". But I'm guessing I screwed up
| editing the code when I switched everything to "tail". :)
| DonsDiscountGas wrote:
| The title and graphic suggest an article about the most delicious
| treat known to humans, and the post is about software. My
| disappointment is immeasurable and my day is ruined.
| chankstein38 wrote:
| Yeah I clicked here thinking this would be an interesting story
| about why macarons are so popular these days or something. When
| I saw a code block I closed immediately. I'm a programmer but I
| don't care about every random, poorly-named library or
| framework that exists.
| apetresc wrote:
| To be fair, it's not a library or framework, it's a format
| for certain types of security tokens. They're kind of like
| fancier cookies, hence the name "macaroon". Not so poorly-
| named, in my opinion (to the extent that "cookies" was ever a
| sensible name). Just the right level of whimsy while still
| calling back to what they are.
| bbarn wrote:
| A macaroon is a mixed up ball of coconut and egg whites. A
| macaron is the delicious fancy sandwich cookie.
| dataflow wrote:
| And for completeness, a Macron is the president.
| amenghra wrote:
| Not to be confused with micron, which is the size of most
| politicians' accomplishments after they get elected.
| rsynnott wrote:
| This is an obscure form of nominative determinism.
| Biscuits tend to be named after French leadership (eg
| Bourbon, Napoleon, etc), thus obviously someone whose
| name is nearly a biscuit should become leader of France.
|
| (There are also Garibaldi biscuits, which would at first
| seem to dilute the theory... but he was born in France!)
| amenghra wrote:
| Referer/referrer, macaron/macaroon, the web isn't good
| with typos...
| BobaFloutist wrote:
| And macaroni is a kind of pasta. Make it make sense.
| patja wrote:
| It is an oddly specific choice to use the word macaroon for
| this, given the widespread confusion over macaron vs.
| macaroon and how many other unambiguous variants of
| "cookie" are available for naming a piece of software that
| is a newer fancier cookie. I do not accept Wikipedia's
| milquetoast concession to call a macaron a "French
| macaroon".
|
| Was it intentionally named as an allusion to this
| confusion? Software is full of hand-wringing over naming
| and the importance of naming. Is it supposed to be a kind
| of cookie that is often mistaken for a different cookie?
|
| Or is this just another referer, a mistake that has been
| accepted as canon. Referer has the benefit of not being a
| real word at all though, so is less confusing.
| jpolitz wrote:
| As far as I remember (maybe Arnar or Ulfar or another of
| the authors would have a different memory, though) we
| just wanted a "cool cookie" name. We knew about the
| -oon/-on distinction and liked the sound of -oon.
|
| I view it as a mild plus that the confusion around the
| name has educated so many about confectionery taxonomies.
| Tade0 wrote:
| If you type a name in your search engine of choice and the
| intended link is not on the first page of results, then
| that name might not be the best.
| patja wrote:
| When I saw the title and graphic I assumed it would be an
| article about conflict over cultural/language imperialism.
| Waterluvian wrote:
| Furthermore, I live where macaroon and macaron are spelled,
| pronounced, and taste different.
| Jun8 wrote:
| Not to be confused with macarons, which are also delicious but
| have no SW design named after them!
| adverbly wrote:
| Or macron, which is a president.
| Jun8 wrote:
| OK, spurred by your comment I consulted my large Larousse
| dictionary and found these two: _macon_ (builder) and
| _macon_ (a wine). I challenge others to find others in the
| 'm _c_ [r]*n' form.
| toyg wrote:
| Well, there is Macron the sports apparel maker...
| dbatten wrote:
| To make matters worse, the title and featured image make it
| very clear that they have confused "macaroons" and "macarons."
|
| Macaroon: https://en.wikipedia.org/wiki/Macaroon Macaron:
| https://en.wikipedia.org/wiki/Macaron
| carbine wrote:
| THANK YOU
|
| came here to say this
| ryanjshaw wrote:
| This hurts my braincell.
|
| On "macaroon":
|
| > The name "macaroon" is borrowed from French macaron
|
| On "macaron":
|
| > A macaron, or French macaroon, is a ...
| evancordell wrote:
| To be fair, this is a mistake that started with the Google
| paper, and everyone else just copies the mistake.
|
| The paper calls them Macaroons as a play on (browser) Cookies
| with layers (of caveats) - so clearly they meant macarons as
| well, since a macaroon doesn't have layers. Or at least,
| that's always been my interpretation of the name. It's
| possible it was just an arbitrary play on hMAC cookies and
| not the layers?
| matthewaveryusa wrote:
| >and escape hatches like Mutation (for our GraphQL API).
|
| Can you explain in a bit more detail what you mean by escape
| hatches (sounds dangerously fun)
| tptacek wrote:
| The Organization -> Apps -> Volumes (whatever) structure models
| our problem domain and is a sort of coherent abstraction. If we
| get that abstraction wrong, it's a pain to retrofit changes.
| Caveats like "Mutation", on the other hand, are simply strings
| representing calls you can make in our API; they're not a model
| of anything. I don't think we use `Mutation` for anything right
| now, but it's there in case we (or you) ever need a token that
| authorizes a particular set of GQL calls that don't fit the
| model we came up with.
| jzelinskie wrote:
| It's probably more relevant to your previous blog post that did a
| survey of technologies, but I'm curious if y'all ever considered
| a fully centralized approach. Is there something about Fly that
| benefits from a decentralized approach?
|
| Disclosure: I work on SpiceDB alongside maintainers like the
| pymacaroons author
| tptacek wrote:
| Can you define "centralized" and "decentralized" for me? What
| would a "fully centralized" approach to this problem look like?
| jzelinskie wrote:
| Sure thing! These terms may not be the best way to
| communicate these concepts. Would love your take on that,
| too.
|
| I used the term decentralized to describe claim-based token-
| passing authorization strategies because the data defining
| their access is being source from various services,
| attenuated, and passed around with the request.
|
| I use the term centralized to describe something where all
| the data defining access and the policies are sourced from
| one service. I personally work on a Google-inspired system,
| but there are plenty of policy engines using a similar
| approach.
| tptacek wrote:
| Couple thoughts.
|
| * With regards to the "core Macaroons" we implement with
| first-party caveats, we conceptually are centralized, in
| that there's a single source of truth about which apps
| belong to which orgs &c that caveats are evaluated against.
|
| * The basic challenge we have is providing a comparable
| experience in every data center we're operating in around
| the world, so a "purely" centralized model would be
| problematic for us; people in Sydney would get a much worse
| experience than people in Ashburn. We get around this with
| LiteFS, to an extent. This post undersells how important
| LiteFS is to the deployment model here.
|
| * With respect to having, like, a Zanzibar-like access
| matrix dealy: part of the thing here is not wanting to have
| to provide a single coherent permissions model to our
| users, because our problem domain is so broad and we will
| get it wrong. Providing orthogonal tools to let users
| express things seems like the better strategy to us? But
| there are upsides to both approaches.
|
| * Of course, one of the big wins here, that we have a
| plugin interface for authorization, depends on some measure
| of decentralization.
|
| I feel like this is kind of a scattershot response, but
| hopefully I hit some of what you were talking about, and
| you can let me know if I've missed the mark completely.
| X-Istence wrote:
| Macaroons are also implemented and used by pypi.org's
| implementation named Warehouse:
|
| https://warehouse.pypa.io/development/token-scanning.html
|
| Also see:
|
| https://pypitoken.readthedocs.io/en/latest/
| woodruffw wrote:
| Yes, although PyPI doesn't currently do much attenuation or
| delegation with them (this is largely my fault, since I didn't
| fully understand their power when picking them for the
| implementation).
|
| That's been slowly changing, however -- as of a few months ago,
| PyPI issues slightly more compact API tokens that make better
| use of discrete caveats. They're also used on the Trusted
| Publishing[1] side to make the API token self-expiring.
|
| [1]: https://docs.pypi.org/trusted-publishers/
| iou wrote:
| lol, the picture in the post is of a macaron, not a macaroon
|
| https://www.foodnetwork.com/recipes/packages/baking-guide/ma...
| sergioisidoro wrote:
| So, are Macaroons are like a "blockchain", where each block is an
| attenuation (ie reducing permission and scopes) of the permission
| of the original token? So a bearer can get a token, reduce its
| scope (without talking to the server) and pass it down to other
| less privileged entities. That's cool!
|
| I kind of had to look into the paper linked to really understand
| what they are. I feel the article could have given a bit more
| context on it :)
| dwaite wrote:
| Somewhat. It is symmetric key based, so only the initial issuer
| can do verification. It is not part of a distributed data
| store, so there can be multiple copies (and derivatives) of a
| macaroon floating around.
|
| Basically, a trusted service creates an initial atom and shares
| it with the initial party.
|
| That trusted atom can be copied and shared. Anyone with a copy
| can amend additional information to it, and share those copies.
| Based on the copy you get, you can't remove or alter any
| information received.
|
| So it works best for representing restrictions - maybe my user
| agent gets a token that gives full access for a project. It
| shares a version with another service endpoint which is
| restricted to read-only access. That service endpoint sees it
| needs to kick off a background process, so it creates a version
| which also adds on a 4 hour time limit.
|
| None of these changes are necessarily authenticated - I don't
| know that it specifically was the user agent that shared the
| token with the service or added the read-only restriction, at
| least with the core tech.
|
| You have to create a domain language to specify all of these
| things. If you want restrictions to be authenticated, you need
| to describe how to sign them individually with PKI.
|
| While HMAC is fast, you still have the whole system rooted in a
| single trusted service that can mint any messages it wants or
| lie about the validity of a given message.
|
| So while it is indeed a chain of cryptographic elements, it is
| missing the multi-party validation and operation transparency
| which are the common selling points of distributed ledgers.
| tptacek wrote:
| Biscuits have single roots of trust too. The (superficial)
| distinction is that Biscuits can be verified (completely) on
| systems that don't hold the root keys. You can't do that with
| a Macaroon, but, as we explain in this post, you don't have
| to. I don't think we'd meaningfully gain security from
| Biscuits --- though we would potentially get flexibility from
| Datalog, and our deployment story might have been a little
| bit simpler.
|
| (We already need hardware-isolated secret stores, so the
| deloyment win is probably marginal for us, but it's a bigger
| deal for other shops).
|
| Purely symmetric cryptography is one of the features of
| Macaroons. It's a reason cryptography hipsters like it, not a
| reason to dunk on it.
| dwaite wrote:
| Yep, comparing SHA2-based macaroons and ED25519-based
| biscuits, you'll have size and computational performance
| advantages for macaroons as well as post-quantum
| resistance.
|
| But that doesn't help you if you want to solve the network
| performance and failure issues with verifying macaroons.
|
| There may be strategies to solve some of the biscuit
| disadvantages using different signature mechanisms like
| BLS, but that might not help with performance and will not
| currently get you post-quantum resistance.
| tptacek wrote:
| The back half of this piece is largely about the network
| performance and deployment issues of Macaroons and how we
| addressed them. This is a real system, running in
| production; it isn't a proposal.
| arnarbi wrote:
| > None of these changes are necessarily authenticated - I
| don't know that it specifically was the user agent that
| shared the token with the service or added the read-only
| restriction, at least with the core tech.
|
| Macaroons are very much grounded in capability thinking,
| where it is a "feature" that principals such as the user
| agent in your case don't need to have representable
| identities. So there's nobody to authenticate, except the
| fact that it was a holder of the previous macaroons tag,
| which means they had the authority it represented.
|
| In other words, not needing something like a PKI is somewhat
| the point of it all.
|
| If you have the need to authenticate the intermediate
| principals, eg because they have pre-existing identities
| already, then the capability model in general may just be a
| distraction. They could just sign their desired attentuations
| with their own identity key.
| k__ wrote:
| Are macaroons similar to UCAN?
|
| https://ucan.xyz/
| jszymborski wrote:
| This post was written exceedingly well. Few posts execute humour
| and whimsy without coming off as insincere or just not very funny
| (I'm guilty myself).
|
| Bravo!
| robbles wrote:
| The tone is entertaining, but some of the snarkiness around the
| code is bit frustrating at times. e.g.
|
| > # do i really need to say I'm not serious about this?
|
| Can you just come out and say what you mean here? Like,
| presumably it's bad, insecure code, but can't you just spell it
| out for the benefit of your audience?
|
| I'm probably being really picky here - just find this kind of
| developer in-crowd signalling to be really irritating and
| counterproductive.
| tptacek wrote:
| The Python code here is essentially just pseudocode. In
| reality, if you build a Python Macaroon implementation, you'd
| pull in pyca/cryptography and use an actual AEAD, rather than
| rolling your own authenticated cipher out of pure HMAC. But
| the point is that this isn't real code, just enough to make
| the concepts concrete.
| byproxy wrote:
| I can always appreciate that these types of stripped-down
| examples are merely for illustrative, conceptual
| purposes...but the ignoramus in me would also appreciate
| links to fleshed-out examples that take into account the
| shortcomings of the simpler example.
| tptacek wrote:
| Our actual Macaroon code is linked at the bottom of the
| article.
| robbles wrote:
| That's a great explanation, and pretty much exactly what
| I'd love to see instead of the original slightly mysterious
| comment :)
| cide1 wrote:
| I studied that code and the comment for a good 10 minutes. As
| far as I can tell it just obfuscates, and is not actually
| implementing authenticated encryption. It would help to just
| come out and say that part out loud.
| tptacek wrote:
| True fact: Salsa20 is itself a hash function, keyed, and
| running in a counter mode.
| oneepic wrote:
| >I'm probably being really picky here - just find this kind
| of developer in-crowd signalling to be really irritating and
| counterproductive.
|
| Why is it "developer in-crowd signalling" rather than just a
| joke? IOW I read this as saying the jokes were "as bad as"
| virtue-signalling.
| robbles wrote:
| It's a statement that won't make sense to someone who's new
| to the topic.
|
| I don't think it's related to virtue signalling at all, the
| two just share the word "signalling".
| wereHamster wrote:
| I wonder why they went chose macaroons over biscuits. The later
| is only mentioned once in that article, but doesn't talk about
| why they were not selected.
| tptacek wrote:
| I like Biscuits, wrote about them before, and recorded a
| podcast episode with Geoffroy Couprie about them+.
|
| The short answers:
|
| * When we started working on this design, there was still some
| uncertainty about the elliptic curve chaining construction (as
| in: they hadn't, or maybe had just started to, work out which
| one they were going to use).
|
| * We do _a lot_ of verifications, and the prospect of running
| lots of 25519 computations every time we have to check a token
| was daunting; by comparison, HMAC is essentially "free".
|
| * I'm not especially scared of Ed25519, but asymmetric
| signature cryptography is much more complex than computing a
| MAC. Like I said in the post, one of the great charms of
| Macaroons is how much mileage it gets out of a construction
| that everyone understands, and that doesn't have sharp edges.
|
| * Geoffroy sold me on the value of using a logic language to
| express caveats, but that was much more complicated than what
| we felt we needed. Another charm of Macaroons is that they're
| rigidly coherent; just an unordered collection of true/false
| predicates, loop over them and if any fail reject the request.
| I feel safe expressing things with Macaroon caveats --- not in
| the sense of "the token implementation doesn't have bugs", I'm
| sure Biscuit's Datalog is fine, but rather in the "I'm not
| going to mess this up as a user" sense.
|
| * We needed implementations in a bunch of different languages.
| Biscuits have them, but owning the implementation ourselves
| derisked things for us. We could have owned an implementation
| of Biscuits, but I'm not smart enough to do that well.
|
| +
| https://securitycryptographywhatever.com/2022/01/29/biscuits...
| camgunz wrote:
| Can't speak for them, but I've heard people balk at the Datalog
| part (IMO not an issue, but I'm not everyone)
| michelpp wrote:
| I like the "solve the now" perspective here, and having code
| examples is very helpful to understand some of the rational
| behind the approach. Having read your previous "tedious
| survey"[0] post on various token formats, I generally agree with
| a lot of your conclusions. Curious though about your thought
| process wrt macaroons vs biscuits.
|
| To me the one major downside of macaroons has always been the
| single shared root symmetric key. Many use cases are addressed by
| third party attenuation, but then there are the problems like key
| rotation, having to do online verification, no built in
| encryption, no peer-to-peer support through an "untrusted"
| fly.io, and no third party token verification without decryption
| like in signcryption[1] schemes. Of course this is traded off by
| having to do PK issuance and management so I can see the
| simplicity of it.
|
| Is fly.io scoping this pretty hard to just auth tokens with third
| party attenuation, or do you see further development and maybe
| moving to other token systems like biscuit when/if the need
| arises to address those known issues?
|
| fwiw I've done a bit of research work myself on a token format
| using signcryption [2] where I explored addressing some of these
| ideas (but not the attenuation side of it yet, which I get is a
| big deal here).
|
| [0] https://fly.io/blog/api-tokens-a-tedious-survey/
|
| [1] https://github.com/jedisct1/libsodium-signcryption
|
| [2]
| https://github.com/michelp/pgsodium/blob/feat/signcryption-t...
| tptacek wrote:
| We're not going to use Biscuits. The "single root symmetric
| key" thing is a systems design challenge for us, not a
| cryptographic one: we simply isolate the key handling on a
| software-HSM-like verifier service, running on dedicated
| hardware. If you're coding authz logic for Fly.io's platform
| code, your experience will be that you can manipulate and check
| Macaroon caveats without ever having access to the keys
| themselves, because we split Macaroon-checking into
| "verification" and "caveat clearing".
|
| The threats in this design that would force us to do abrupt key
| rotations and mass token invalidation are thus pretty much the
| same as the ones we'd face with Biscuits; the "trusted code
| base" of key-handling code is comparably small.
|
| More detail here:
|
| https://github.com/superfly/macaroon/blob/main/macaroon-thou...
| tptacek wrote:
| Back in 2021, when I wrote the API token survey post, I had some,
| uh, caveats about Macaroons, and linked to a talk from a
| developer at Chain who had gone through the experience of
| deploying them. Don't get me wrong, it's still an excellent
| talk+, but after working on implementing them for a year or two I
| find it much less damning than I did at the time.
|
| One problem Chain seemed to run into was coupling between their
| services. They had a fast Golang "ledger" and a slow Rails
| "dashboard", and found that Macaroons forced all their requests
| to loop through the "dashboard". This was because they'd opted to
| do short-lived Macaroon tokens that needed to be reissued every 5
| minutes (eminently sane), and only their dashboard could generate
| the proper token?
|
| Another problem they had with Macaroons: their Rails dashboard
| has an RBAC permissons interface. But once they've issued a
| Macaroon, users can't change permissions with the interface
| anymore. But that's a problem with all stateless tokens, not just
| Macaroons; in fact, Macaroons probably help here, because if
| you're presenting a Macaroon to the dashboard interface in the
| first place, the RBAC interface can just attenuate it for you and
| hand it back to you.
|
| I still think this is a design that mostly makes sense only if
| you have a problem domain for which both attenuation and
| delegation make sense. Most basic CRUD apps don't have these
| problems, and using Macaroons would be a mistake for them.
|
| + https://www.youtube.com/watch?v=MZFv62qz8RU
| leoqa wrote:
| I'm curious what your thoughts are on implementing a sane
| authorization system in 2024. You mentioned writing roles onto
| macroons but what does your policy look like? Is your surface
| area simple enough that it's not a concern?
|
| I've been on various security teams with disjoint product-
| facing authz, internal authz and service authz policy engines /
| mechanisms etc. Additionally, authz gets baked into service
| code and product interfaces, so it's hard to change later.
| tptacek wrote:
| The idea is that Macaroons are a low-level IAM language,
| designed close to the components that they pertain to,
| encoded directly into the tokens, and that higher-level IAM
| policies "compile down" into those tokens.
| leoqa wrote:
| If you need more content, I would be keen to read a blog
| post on how you designed authz at Fly.io. I think it'd be a
| unique point of view, given your security background and
| ability to write well.
| dullcrisp wrote:
| In the third_party_caveat code sample, I think you mean to be
| passing in the tag rather than the url, and the arguments at
| the call site are in the wrong order.
|
| Edit: Or I guess along with the url.
| tptacek wrote:
| You're right; I extracted that function from a gnarlier
| function I didn't want to use in the post (it was the same
| logic, but the function was so long it broke up the post too
| much) and wasn't careful enough in moving the code. Fixed,
| sort of! Thanks!
|
| Go easy on me; I literally wrote this in IDLE.
| elbasti wrote:
| What I really want to know is how fly.io has recruited such
| talent. @tptacek (who wrote this article), @chrismccord (creator
| of elixir Phoenix/Liveview), and others.
|
| Very impressive, but also slightly worrying since some parts of
| fly.io have such terrible DX/documentation. I've only recently
| started using them, but the documentation around billing and
| databases is shockingly bad for a team that is clearly so deeply
| stacked.
| dartos wrote:
| Out of curiosity, what database documentation was lacking?
|
| IIRC they don't provide a managed database, just like a
| template
| elbasti wrote:
| Right. They provide a convenience function that spins up a
| machine running postgres and adds the right environment
| variables to any machines you already have running.
|
| It's "just another machine," but that's not obvious when
| you're setting it up! Two bits of documentation that are
| lacking here are:
|
| 1. How does this affect billing, especially if you're on the
| hobby plan? (Answer, as far as I can tell: since it's just
| another machine, it can be free _if and only if_ you resource
| it such that it fits in your free "allowances." The defaults
| are NOT these, however, so you have to be careful if you want
| to mess around for free).
|
| 2. Once the db machine is created...how can I get credentials
| for it? A connection string is generated upon machine
| creation but...what if you don't write it down?
| verelo wrote:
| Yeah i feel your pain here. Fly has a lot of things that
| feel like they're hidden features, or at least,
| undocumented. Like, its trivial to get all the env vars
| from a machine, but i couldn't find this in the
| documentation anywhere. Someone else i was working with
| told me how and now..i know?
|
| fly ssh console --command env
|
| To be fair, it is mentioned in their docs, i just couldnt
| find it searching things like "how to find my environment
| variables".
| arccy wrote:
| part of it is common sense: fly ssh console == ssh, and
| then you run env to print the environment variables in
| your current session (which may not be the exact set of
| envs your app sees).
| tptacek wrote:
| There's a whole backstory to this, because we got a big
| influx of Heroku developers a couple years ago, and
| Heroku developers all expect to be able to dump all their
| environment variables, including secrets, from the
| command line or whatever. We don't do that: our API is
| like a diode for secrets, and once they're set, they're
| sealed into a cryptographic vault on separate hardware.
| It is and has to be the case that you can shell into a
| machine and get the secrets, which apps all expect to
| receive in environment variables, but we don't _like_
| that you can do that, and wouldn 't want to encourage it.
| Environment variables are hazmat!
| verelo wrote:
| Right ok that makes sense. The reason i wanted this was
| for the reason mentioned earlier in this thread: you spin
| up a DB but don't have the credentials. Fortunately i had
| stored them as an env var and was able to recover them,
| but otherwise i felt at a loss on how to gain access.
| tptacek wrote:
| Right, that's exactly the kind of environment variable we
| don't want you to be able to easily retrieve.
|
| Interestingly, there's a big intersection with Macaroons
| here. We're replacing Vault (for customer secrets, not
| for TLS keys or infra secrets) with an internal,
| Macaroon-integrated secret store called Pet Semetary, and
| one of the use cases for it is to come up with a high-
| assurance way to give customers straightforward access to
| secrets without having to reverse engineer them from
| their machines.
|
| At any rate: this is all a consequence of our security
| model. A vulnerability in our Rails API server (which is
| not, like, beyond the frontiers of possibility) would
| give you enough access to jumble up everyone's secrets,
| but not to read them. We're happy to take our lumps for
| how annoying that makes our DX sometimes. :)
| chubot wrote:
| Part of it is probably that smart people want to work on harder
| and more ambitious problems, which YC advisors seem to say a
| lot. And also smart people want to work together
|
| As I understand it, fly.io built a cloud from scratch, from the
| hardware up. That's HARD. It's typically something only well-
| funded companies like Amazon / Google / Microsoft do, with
| billions of dollars in products to justify it. Cloudflare is
| another company that pretty much did it, and it seems to have
| taken similarly ambitious engineering (although maybe theirs
| isn't fully general purpose)
|
| https://fly.io/docs/about/security/ - _We run on our own
| hardware deployed in secure data centers like Equinix_
|
| Most cloud companies in the 2010's built on top of other clouds
| like AWS. For example, Heroku and I'm pretty sure dotCloud, the
| company that became Docker.
|
| I always thought that was a weird design, but it definitely
| saves you a lot of time and hassle. At the cost of a lot of
| software complexity and platform risk.
|
| Even so, there were at least 20 or 30 of these companies, and
| most of them didn't make it.
|
| Google App Engine (one of the first PaaS like Heroku, circa
| ~2007) also built on top of Google's data centers and Borg of
| course. They didn't manage their own hardware -- they used
| another cloud for that!
|
| From the outside, "hosting" may all look kind of similar, but
| there are worlds of difference under the hood.
|
| ---
|
| I'll also say that the subject of this blog post -- cloud
| security -- is extremely hard.
|
| FWIW I joined the team that published the Macaroons paper ~10
| years ago, and I tried to implement Macaroons as a side project
| then (for about a week, it wasn't very serious). I was looking
| for something simpler and more elegant, but there's no real
| magic bullet, and I think this post kinda concedes that toward
| the end.
|
| But when you have really hard problems, it's not surprising if
| the solution is really complex!
|
| The problem can actually be infinitely hard, because you have
| adversaries that are both more powerful, and that adapt.
|
| Google learned this the hard way ~10 years ago when it learned
| that BOTH the United States government and the Chinese
| government had successfully attacked it :-/
|
| People seem to forget about these incidents:
|
| https://en.wikipedia.org/wiki/Operation_Aurora
|
| https://en.wikipedia.org/wiki/MUSCULAR
|
| https://www.washingtonpost.com/world/national-security/nsa-i...
|
| So basically, if you are successful, then it earns you more
| problems :)
| hinkley wrote:
| I think they've stopped talking about it but there used to be
| commentary from Google's "Better to turn down a good person
| than hire a bad one" logic (Or was it Facebook?) about how a
| C-employee can't evaluate an A-employee, and so they hire
| B-employees and it becomes a race to mediocrity.
|
| My last hiring cycle I just missed working at a place with a
| couple guys who I dove pretty deep with on some esoteric
| topics over beers at a handful of tech meetups. The job req
| got weird and I had already accepted a position by the time
| it got sorted out. But lots of people have stories like that.
| It's one of the reasons people go to those meetups. I think
| for a lot of us it's being able to talk to someone who can
| keep up with your stream of technical talk, but the business
| contacts are a lovely bonus.
| windlep wrote:
| I remember when I saw a presentation by the macaroon authors a
| few years back, there were pending patents that Google filed
| around them. While the authors claimed Google wouldn't sue
| anyone, I'm always a bit skeptical about such claims. I thought
| macaroons would be helpful for some of my use-cases, but since I
| now knew there were patents that'd be wilful infringement so I
| didn't bother.
|
| I can't find the patents now, so perhaps they were rejected or
| withdrawn. I had assumed that was why macaroons hadn't caught on
| more widely.
|
| Edit: Found the patent:
| https://patents.google.com/patent/US9397990B1/
| everybodyknows wrote:
| The Pythonish pseudo-code, rendered to an image (figure 7) --
| is that common nowadays? Though the patent I see is dated 2013.
| jimmyl02 wrote:
| maybe this is similar to google's patenting of dropout for
| neural networks? you can never know but so far there haven't
| been many adverse effects and they claim that they patent it so
| others can't maliciously patent and enforce it.
|
| dropout patent link:
| https://patents.google.com/patent/US9406017B2/en
| windlep wrote:
| That was what the authors claimed when I asked them about the
| macaroon patent. It'd be nice if Google had a legal document
| associated with patents they never plan to enforce, or the
| constraints around when they might enforce them (e.g. only
| against patent trolls) that a company could rely on.
| tptacek wrote:
| There are so many stupid patents out there about everything we
| could possibly work on, it is actually reassuring to see that
| Google is assigned to some of them, rather than to some
| storefront in Marshall, Texas.
| surajrmal wrote:
| Google has an open pledge to not litigate open source uses of
| its patents: https://www.google.com/patents/opnpledge/pledge
| diggan wrote:
| What does a "open pledge" like that realistically mean, in
| case they someday broke that pledge? Would the court-case
| 100% surely get thrown out? Am I legally protected because of
| this pledge?
| esafak wrote:
| Just look at their litigation record. They have been around
| for long enough to have a meaningful track record.
| RussianCow wrote:
| That doesn't mean things won't change in the future.
| windlep wrote:
| The patents page
| (https://www.google.com/patents/opnpledge/patents/) does not
| include the macaroon patent. Maybe they forgot to update it?
| 8organicbits wrote:
| > we want Macaroon tokens to be safe to transmit between users
|
| How does this work for auditing? If user A gives user B a token
| (perhaps after adding a caveat) how does this system audit log
| determine who did what? Does that require a third party system?
| tptacek wrote:
| You can get as many independent Macaroons from us as you want,
| so while there are ways to handle this with third-party caveats
| (and never talking to our servers to get another token again),
| the simpler thing for token provenance with our system is the
| same as it would be with any other: just issue multiple tokens.
| dwaite wrote:
| There is no centralized auditing of derivative macaroons, but
| there could be of verification of those macaroons - you still
| require a centralized service which knows the core HMAC secret
| to give a thumbs up or thumbs down.
|
| To that end you can define auditing information even when there
| aren't really caveats - user A appending that they are giving a
| version of the macaroon to user B with no restrictions on use.
|
| Since there isn't a domain language, you have to define all
| this. JSON can be useful to have an extensible notation for
| describing this, although you need to up-front declare the
| difference between information which can be ignored and caveats
| which much result in failure if not understood.
| tptacek wrote:
| Note also that in our scheme, if Alice attenuates a token and
| gives it to Bob, Bob will still have to hit our login service
| to "activate" the token (that's the word I should have used
| in the post and I'm kicking myself for not thinking to
| express it that way) by clearing the third-party auth caveat
| we put on every token. So it's not as if we have no auditing
| of token delegation.
|
| Still: if only for revocation purposes, I'd probably just
| mint a new token for e.g. a contractor (and certainly for
| every user). The nice thing about the system is that you can
| edit the tokens after we give them to you so you're not stuck
| with our role definitions, which I think is a significant
| win, but doing all of IAM without talking to our servers more
| than once, while a cute technical stunt, is probably not all
| that valuable to users.
| fovc wrote:
| Surprised to see JSON here. I recall discussing JWT with tptacek
| a few years ago, and one of the concerns was the {a: x, a: y}
| ambiguity in JSON parsers. Was that a concern with this design?
|
| My other reaction was that this sounds scary:
|
| > a token with no caveats restricts nothing. It's a god-mode
| token. Don't honor it.
|
| I guess it's technically "fail closed" but seems kind of brittle
| tptacek wrote:
| I think it becomes more obvious later in the post that the
| Python code here is for illustrative purposes only. We don't
| use JSON. Our actual tokens are strictly typed. But also: it
| doesn't matter that much, because all of the predicates in a
| Macaroon are evaluated independently. There's no opportunity to
| confuse a previous caveat with a subsequent one. That's one of
| the strengths of having a rigidly coherent design like
| Macaroons, rather than just a bag of keys and values like JWTs
| do.
| fovc wrote:
| Ah thanks for clarifying! I knew the code was illustrative
| but didn't realize the JSON part was too
| hinkley wrote:
| The XML digital signature spec had that problem in spades. It
| took us about five times as long to button it down as it did to
| implement.
|
| By the time I was done with that project, the document for
| partners and vendors (if anyone wanted to implement their own
| instead of using ours) was several times longer than the spec,
| what with all the extra MUST and MUST NOT situations. Which is
| not that hard when you're dealing with swiss cheese.
|
| Document.findById and Element.findById being able to return
| different (non-null) results being the most egregious one I can
| remember.
| dwaite wrote:
| XML is a disaster here all of its own, but is at least
| unambiguous at the parser level.
|
| JSON says "if your document does this, parser behavior is
| undefined". So you need to declare that the parser used
| should behave in particular ways.
|
| Both are best solved a robust specification and supplemental
| test vectors. If you define meta rules (e.g. JSON parsers
| must either fail or return the last object property), you
| still retain the value you hoped for by using something like
| JSON or XML in the first place.
| hinkley wrote:
| Isn't it Turing Complete with namespaces? (that's another
| thing on the SHALL NOT list). Can't be unambiguous if you
| don't halt.
| Arelius wrote:
| These look pretty useful cool...
|
| I'm curious a bit though, here, and in other posts in HN, I often
| see that HMAC, a symmetric key is preferred, going as far as
| suggesting, in JWT, that other algorithms should not be
| implemented. Why is that? What are the problems with say RSA?
| (Ignorning that I'm not sure Asymmetric keys work with Macaroons
| design at all)
|
| From my perspective, Asymmetric keys have been a great boon, in
| that I can keep the private key, secured on my single auth
| server, but then freely distribute the public key to the edge,
| greatly increasing responsiveness, and reducing the bottleneck on
| the Auth server.
|
| Is there some security concern I've been missing?
| evancordell wrote:
| > The community that formed around building open source
| "standard" Macaroons decided to use untyped opaque blobs to
| represent candidates.
|
| I assume "candidates" was supposed to be "caveats" - and as an
| author of a "standard" macaroon implementation, I completely
| agree that this is the biggest downfall of Macaroons. With no
| common caveat language (and no independent "dischargers") it
| really limits their use to within a single org. And at that point
| you're basically asking everyone to invent their own token format
| anyway.
|
| Though I don't personally use them much anymore - I think the
| use-cases for Macaroons are much more limited if you have a
| Zanzibar! - I appreciate seeing Macaroon discussions pop up and
| this post and the related discussions it linked out to were a
| great read.
| bethecloud wrote:
| Storj is also leveraging macaroons. Great write-up on
| decentralized access control here:
| https://medium.com/@kleffew/what-is-capability-based-securit...
| ijustwanttovote wrote:
| Small detail, there's a picture of macarons and not macaroons.
|
| A macaron is a sandwich-like cookie that's filled with jam,
| ganache, or buttercream. A macaroon is a drop cookie made using
| shredded coconut.
| arnarbi wrote:
| Macaroon is just the English word for the French word macaron.
|
| _ducks for cover_
| beAbU wrote:
| Macaroon is a completely different confectionery:
| https://en.m.wikipedia.org/wiki/Macaroon
| IshKebab wrote:
| Sure, but Macarons (the burger-looking things) are also
| sometimes known as "macaroons". Yeah.
|
| Examples:
|
| * https://missmacaroon.co.uk/
|
| * https://www.floristgrays.co.uk/design-202300010/valentine
| s-m...
|
| * https://www.parisiennesouthwell.com/product-
| page/macaroons-v...
| RussianCow wrote:
| The fact that people say it doesn't make it any less
| wrong. :)
| recursive wrote:
| If enough people do it for long enough, it does. After
| all, that's how we got the rest of the words.
| Julesman wrote:
| Don't let anyone try to convince you that up is down. Word was
| spelled wrong. Period.
| denton-scratch wrote:
| Title looks like the kind of word-salad you'd get if you asked
| for a three-word passphrase made from random dictionary words.
| tptacek wrote:
| Good note.
| beeks wrote:
| it seems to me that macaroons could get quite big in order to
| adequately describe allowed resources and permissions? Especially
| if the API is broad? Much bigger than JWTs.
| tptacek wrote:
| The resource descriptions are pretty parsimonious; they're
| binary-encoded MsgPack integers, for the most part. But the
| cryptography eats up a lot of bytes. They're bigger than JWTs,
| but probably by a factor less than 2 (I don't know the median
| JWT size). Basic take: unless you can golf your tokens down to
| a single terminal line, it doesn't much matter how much bigger
| or smaller they are. These are all smaller than X.509
| documents.
| xbar wrote:
| I am not a customer, but I do like the fly.io "voice."
___________________________________________________________________
(page generated 2024-01-31 23:00 UTC)