search

w3ctag / capability-urls

Work on good practices for the use of capability URLs
http://w3ctag.github.io/capability-urls/
33 stars 17 forks source link

Easier to leak #10

Open annevk opened 7 years ago

annevk commented 7 years ago

Maybe it's worth mentioning that capability URLs guarding some kind of secret are easier to leak with third parties than URLs with credentialed access. As credentialed access points directly back to the leaker.

That doesn't prevent a motivated leaker, but it goes back to URLs being easy to share and are therefore not the best place to place secrets.

See https://daringfireball.net/linked/2017/09/12/locking-it-all-down for a recent case.

metaweta commented 7 years ago

credentialed access points directly back to the leaker.

If you issue different capabilities to different individuals, then it's clear whose authority was used to view the secret. It's the underuse of capabilities that was at fault in the example you cited, not the overuse.

annevk commented 7 years ago

Sure, but for typical capability URLs as deployed there's just one for a given resource. And a system like the one you advocate wouldn't work well with browsers I think where there is an incentive for users to copy-and-paste URLs.

kephas commented 4 years ago

By what measure is it "typical" to have just one URL per resource?

In all literature on object-capabilities, it is pretty typical to share resources through a caretaker, thus creating a new URL for each share, when using capability URLs.

Also, if high security is needed, as for secret firmware, the way Github or Google Docs are implemented doesn't seem like a reasonable baseline. They are definitely not designed for auditable high-security.