- From: Martin J. Dürst <duerst@it.aoyama.ac.jp>
- Date: Fri, 26 Mar 2010 15:31:15 +0900
- To: John Kemp <john@jkemp.net>
- CC: "www-tag@w3.org WG" <www-tag@w3.org>
Various comments of different nature below.
On 2010/03/25 22:14, John Kemp wrote:
> 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
Well, 'most secret' means known to nobody :-). That sometimes happens
when people forget their passwords.
> 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)
control chars -> punctuation, symbols
+ don't show (use ********** when typing in)
> 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
+ don't show (not directly visible in browser)
> 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?
One more downside:
URIs are in general used publicly, and are visible (e.g. over the
shoulder) in a browser. The 'secret' URIs aren't marked as such. It's
therefore easy for users to misunderstand and think they can share them.
Regards, Martin.
--
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp
Received on Friday, 26 March 2010 06:32:07 UTC