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

coderman coderman at gmail.com
Tue Sep 27 20:46:27 UTC 2005


On 9/27/05, Tyler Close <tyler.close at gmail.com> wrote:
> ...
> 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.

i would love to see the research behind this, as this is an intriguing
approach.  i did not mean to imply that username/password was required
for distinct user authentication (passwords are broken anyway, right?
:) but rather that some mechanism be used to ensure that access to
resources can be constrained at a user level and audited at a user
level.

this is trivial to do if you ensure that no two users are given the
same resource password; each use a distinct name to reference the same
underlying resource.  consider revocation of privilege: if there is no
distinction between users than revocation of privilege to access a
resource is performed on the resource as a whole and would affect all
users (as they are all referring to the resource with the same
password).

if there is distinction between users then revocation of privilege can
be applied to just that user which has violated a trust of some kind.

note that in either case you are still using a password to access
resources, and there is no need to authenticate users solely for the
purpose of authenticating a user (username/password), but rather the
passwords used to access resources imply a distinct user identity
doing so.

while this is not necessary in every case i think this is useful
particularly in the context of privilege revocation / auditing.


> 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 agree with respect to an authentication step required for
identifying a user and for no other purpose (username/password
required before accessing resources via password).

would the multiplicative effect of distinct resource passwords per
user (when user distinction is desired) be as baroque and complex as
the username/password scenario in your view?


> 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

thanks for the link; this is indeed an interesting effort toward a
simple and effective least privilege environment without the
cumbersome complexity of explicit ACL maintenance and the accompanying
error prone interface complexity and/or confused deputy issues.

i am particularly interested in the use of virtual machines (xen) and
profiling of file/device/network resource usage for anomaly detection.
 this requires some kind of distributed / collaborative effort to
manage the privileges/authorities associated with specific tasks /
contexts as the requisites may change from release to release or under
new contexts.

i'll try and clarify what i mean by collaborative least privilege
maintenance and how profiling and anomaly detection can assist this
process to make it as simple and self evident to interact with as an
application/process.  (i am not well versed in the theory here and an
offhand attempt to describe would result in confusion more than
anything else...)  this too requires distinction between users at some
level.

best regards,



More information about the P2p-hackers mailing list