Re: Secret URLs and TAG deliberations

On Jan 23, 2010, at 7:19 PM, Larry Masinter wrote:

[...]

> 
> Tyler:
>>> 2. The TAG understands that unguessable URLs are used for
>>> access-control by many of the most popular sites on the
>>> Web. For example, this email contains a Google Docs URL
>>> [1] for a document I have chosen to make readable by all
>>> readers of this mailing list, even those who have never
>>> used Google Docs. Had I not so chosen, these readers
>>> would not have access and I could have shared access with
>>> a smaller group of people, or no one at all.
> 
> The TAG is aware of this usage pattern; I also provided a
> similar URL at the acrobat.com site, and the user interface
> that allows a user to choose this method of distribution.
> But I disagree that this is "Access Control" as meant in
> http://en.wikipedia.org/wiki/Access_control.

Do you then also disagree that proof-of-possession of a secret key (where the secret key is "an attribute of the requester") is a method of ("attribute-based") access control?

[...]

> Secret entrances (without access control properly in place)
> are very weak (laughably weak) methods of protection.

The use of secret keys in PKIs has been reliable I believe, and access control based on that particular  "proof-of-possession" attribute of the requester seems quite strong - mainly because it is hard to guess the private key associated with a particular public key, there are strong (even technical) disincentives for the possessor of the private key to share it, and that the private key was not shared with anyone. If those assumptions are violated then PKIs become weak methods of protection too. 

> Anyone
> following Max and Agent 99 can see them drop in the phone
> booth and know how to get into CONTROL headquarters, and
> anyone following a "Referer" path from an otherwise
> protected page or document can get access.

That is one very good reason to dissuade those who create URI secret keys from sharing them in ways where the key gets "accidentally" put into the Referer header.

> 
> Tyler:
>> 3. Some members of the TAG believe that an unguessable
>> https URL is a "password in the clear", but that sending
>> someone a URL and a separate password to type into the web
>> page is not a "password in the clear".
> 
> No, someone (Noah?) said that it reminded him of the
> "passwords in the clear" issue and had perhaps some related
> arguments. I agreed that there might be some common factors.
> 
> And it is true that sending someone a URL and a separate
> password is different than sending them a URL which contains
> a password, because one of the exposure points for the
> password are URL proxies and other intermediaries which
> remember URLs used, and send them on using Referer; these
> exposure points are not there for passwords sent back as
> form-data (as long as the form is submitted with POST and
> not GET).  The "password in clear" similarity didn't factor
> in that agreement.

Private keys are only private because they are not shared. Similarly, keys shared between two parties (such as passwords) should be shared privately. If one party privy to a secret wishes to share that secret, then he or she should be free to do so - and URIs are indeed easily shareable. But why not recommend that a secret URI shared by two parties should not be accidentally revealed? 

[...]

> 
> This is interesting, but I don't see the relevance. We
> should acknowledge that "secret URLs" are a common usage
> pattern and that there are some situations where they will
> do to accomplish some goal, even though that goal is not
> "effective access control".

According to the definition you linked to, this seems to be exactly attribute-based access control. It can also be "effective" access control, provided some recommendations are followed - as effective as that provided by proof-of-possession of a password or other shared key. 

> 
> What I think constitutes an effective access control
> mechanism is one in which those using the mechanism have a
> clear understanding of the risks and a means of monitoring
> and correcting failures.
> 
> But designers are often unaware of the exposure risks
> involved in "secret URLs", and so the requirement of
> understanding of risks is not met.

Such risks should be documented, and then perhaps they might become better understood. 

> 
> Further, password-based access control mechanisms often
> allow measurement of the quality of guessability of
> passwords, of detecting intrusions or intrusion attempts, of
> correcting for past errors or intrusions by, for example,
> locking accounts or changing passwords. Using secret URLs
> don't have many of those advantages, and thus it is
> inferior.

Most "secret URIs" I've seen contain a hard to guess random number. If such numbers are generated, and the numbers are shared properly between exactly two parties (just like a password) the guess-ability is provably very low. If you time-limit, or rate-limit such URIs, you can ensure that intrusion attempts are minimized. If you incentivize the recipient of such URIs not to share (or limit sharing) their secrets (just as the credit-card/banking system incentivizes you not to get your card numbers stolen) I would think that such URIs are not only like passwords in their utility, but are much _less_ likely to be guessable (trying doing a "dictionary attack" on a large random number).

Regards,

- johnk

Received on Saturday, 23 January 2010 21:41:08 UTC