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

[coderman]

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*.

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 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.

note that in either case any caching or copying of the resource can
occur by a devious or misguided peer outside of the network where it
was obtained.  (insert long tangent on the dual uses of DRM technology
and hardened hardware)

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'm not convinced that the "unguessability" of the URL is something I'd
> > want to bet on either. There have been plenty of vulnerabilities that
> > allow attackers to guess/predict session id cookies from application
> > servers.
>
> Reading 128 bits from /dev/random is pretty easy to implement. App
> servers with these kinds of bugs are pathetic.

it's a deterrent that makes discovery of unknown but reachable content
expensive.  instead of cracking the holes in a poorly distributed PRNG
(some processing time performed remotely) you now have to bribe the
user's significant other for a copy or discern the identifier bits
from the LED emmisions on the broadband router next to their
computer**.  a sufficiently large nonce would be very near impossible
to guess so you can continue to worry about the other holes in your
system that will leak the same information with a fraction of the
effort.

you could also utilize a variation of hash cash to make attacks
against the namespace more difficult.  "the resource is at
http://peer/[compute 2^20 iterations of the SHA256 digest of
0xdecafbad....]/index.html"

as a side note it's actually pretty easy to deplete /dev/random on a
network server devoid of a monitor, keyboard, mouse and other common
EGD sources.  this is where true random number generators in hardware
can be very useful. (VIA, Intel and AMD all provide hw entropy sources
in some of their products.)

best regards,


* at least, that is my impression of ""Instead of having a password
for each user, have a password for each resource."" as mentioned here:
  http://groups.yahoo.com/group/rest-discuss/message/5231

** side channel attacks are great at rendering well designed (in
theory) and strongly keyed crypto systems completely broken. :)