Secrets

Note: this is a work in progress towards satisfying ACTION-394:

What is a secret?
Secrecy is a continuum - most secret is known to one entity only, least secret is public
Knowledge of a secret can be used as an access-control mechanism, and for authentication

A password is a secret, shared between a user, a user-agent, and one or more websites
What prevents passwords being shared with the world?
  * give them to authenticated, authorized requesters only
  * send them over a secure channel
  * limit accidental or intentional sharing
  * limit "guessability" by making the user include control chars, numbers etc. (a guessable password is subject to a dictionary attack)

A cookie is a secret, shared between a UA and one or more websites
What prevents cookies being shared with the world?
  * give them to authenticated, authorized requesters only
  * cookies can be sent over a secure channel (HTTPS)
  * cookies are only passed on to the domain/path specified by the originator of the cookie (in common non-attack case)
  * limit guessability by making cookie value be a large pseudo-random number

What happens if I change the word 'cookie' to 'HTTP URI'?

An HTTP URI can be a secret, shared between a UA and one or more websites
What prevents URLs being shared with the world?
  * give them to authenticated, authorized requesters only (and tell them not to share with unauthorized, unauthenticated requesters)
  * send them over secure channels
  * limit accidental sharing (other than Referer leakage, what other possibility is there *in the publicly-specified Web architecture* to accidentally share them?)
  * limit guessability by making value include a large pseudo-random number

URIs used in this way, cookies, and user-generated passwords are ALL examples of "bearer tokens" - a weak form of authentication that says "the bearer of this X is allowed access". They are equivalent in this usage. 

Then the question becomes: why bother specifying an additional mechanism with properties roughly equivalent to cookies/passwords?

* Unguessable URIs are used today for some common use-cases; we should describe that usage
* Unguessable URIs can form part of a cross-domain access control model similar but possibly more architecturally sound than the Origin-based model (and eliminating click-jacking, XSRF attacks)

What is the downside?

* URIs might be time-limited, and therefore 404 after some time ("cool URIs *do* change")
* Is it OK to recommend putting the unguessable portion in the fragment ID of a URL?

Received on Thursday, 25 March 2010 13:15:15 UTC