Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

Why not just give every file a name that's a guid or a hash of the content? this works fine with any CDN and it's impossible to guess/fudge. You can only obtain a hash if you have the rights, and while you could share it with others it doesn't seem a bigger security problem than just sharing the picture directly instead of the link.

The only problem I see with such approach is lack of expiration policy (other than re-loading the file under a different name every now and again).



view as:

This is basically like the HMAC(secret, acct#) suggestion further up in the thread. Macaroons are an extension of this idea -- a chain of HMACs instead of a single one.

The idea is to limit the power of the credential, so that when it's stolen, the negative impact is mitigated.

In the paper, they compare macaroons to plain cookies. When you steal a cookie these days, you can take control of an entire account -- maybe even change the password, etc.

In this situation, with the simple HMAC / guid / hash, once somebody "steals" the URL, then it can be leaked to everybody, forever. It can't be fixed without "breaking" the app.

The macaroon technique can also solve the expiration issue. In my post, I described how you would add a caveat for the filename. You can also add a caveat based on time. So then stealing the Macaroon would only authorize the attacker for a limited team -- even a single request (this is talked about in the paper).

A legitimate user can be minted new macaroons constantly based on his login. But the attacker can be locked out based on the expiration. So the attacker's problem is elevated from stealing a single cookie/macaroon to stealing either the login or ALL macaroons, which is generally harder. With Macaroons, you don't have credentials of full power constantly traveling back and forth over the network.

That is my understanding anyway... actually implementing it will probably reveal some more insights.


Legal | privacy