[p2p-hackers] Re: [rest-discuss] Re: RESTful authorization

[Tyler Close]

Hi coderman,

On 9/27/05, coderman <coderman at gmail.com> wrote:
> On 9/27/05, Tyler Close <tyler.close at gmail.com> wrote:
> > Using https is a pretty standard thing to do in a secure web application.
>
> regardless of whether you use TLS or IPsec the main issue with this
> approach is that users are no longer uniquely authenticated, only
> resources are via the nonce or other random looking identifier
> assigned to them*.

Yes, I am proposing that a resource request be honored solely based on
presentation of the correct resource password. Specifically, I am
proposing that username/password checks not be used to authorize
resource access. Based on my study of the problem, I believe using
user authentication to authorize resource access can only confuse the
situation and cause vulnerabilities.

> that is not to say the concept of nonce based locators exchanged
> between trusted parties is not a good idea or useful, just that it
> would be best to combine user authentication _and_ unguessable
> resource locators rather than picking one or the other.  variations on
> this theme can further constrain the availability of the resource
> (like the expiring locators mentioned)

I think such a combination would only succeed in producing a baroque
design with more vulnerabilities. Achieving security requires
stripping away complexity, not adding it.

> i have been playing with this type of constrained distribution over
> wireless using unidirectional broadcast to deliver an encrypted
> payload.  only those with the key (nonce, random locator, etc) are
> provided with access to the resource.  if you use a self
> authenticating name space for file access (sfs) you can also achieve
> this kind of opaque resource identifier mechanism easily.

This sounds like an interesting design. Note that nothing in the above
description implies username/password based authorization.

> for example, user logs into https site using a trusted cert and maybe
> even presents client credentials during the TLS handshake as you are
> concerned  someone might observe their keyboard interactive login
> while using the site.  you then provide them the locator for the
> resource which they proceed to save plaintext on their spyware
> infested directly internet connected windows machine running eDonkey
> and fast track shares on C:\.
> (this is amusing precisely because it is so common)

I agree that this scenario is far too common. Unfortunately, we are
powerless to help the user with a machine infested with spyware. None
of our designs are resilient to running in such an environment.
Fortunately, it is my day job to help build machines that are less
prone to being infected with spyware. See:

http://hpl.hp.com/news/2005/apr-jun/virussafe.html

Tyler

--
The web-calculus is the union of REST and capability-based security:
http://www.waterken.com/dev/Web/

Name your trusted sites to distinguish them from phishing sites.
https://addons.mozilla.org/extensions/moreinfo.php?id=957