Re: Secrets

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