- From: John Kemp <john@jkemp.net>
- Date: Thu, 25 Mar 2010 09:14:45 -0400
- To: "www-tag@w3.org WG" <www-tag@w3.org>
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