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

[Tyler Close]

Hi Antoine,

On 9/28/05, Antoine Pitrou <solipsis at pitrou.net> wrote:
> > On 9/28/05, Antoine Pitrou <solipsis at pitrou.net> wrote:
> > > I'm curious as to how "capability URLs" can't be stolen and re-used by a
> > > malicious piece of Javascript like other URLs can.
> >
> > Simply because a capability URL is unguessable.
>
> It is permanent too,

No, the lifetime of the URL is up to the application designer. Using
capability URLs does not place any duration restrictions on how you
define the lifetime of your resources.

> And you have to keep this URL somewhere... Given that it's full of
> random ascii garbage, you can't keep it in your head (contrast this with
> a properly chosen password), and you don't want to copy it by hand
> either. So it /will/ end up in electronic clickable form somewhere: for
> example in your bookmarks.

I think keeping capability URLs in your bookmarks is a perfectly
sensible thing to do, providing you then protect your bookmarks. I run
OS X, so my entire filesystem is encrypted, including my bookmarks
file.

> >From your own explanation on the REST mailing-list : « The user just
> *clicks on hyperlinks*, without ever needing to be aware of the resource
> password. » Those hyperlinks have to be somewhere...
>
> (and of course, this totally mandates HTTPS, which is impossible for
> most Web sites for reasons I already explained)

This argument is a little out of date. You can get affordable HTTPS
hosting from providers like GoDaddy and 1and1. Even before the advent
of shared hosting for HTTPS, colocation was already an affordable
option and likely required anyways in order to get the performance
characteristics that you want for your web application. For very small
scale projects, running Apache on your home machine with a dyndns
hostname and a 7.99 SSL certificate is also doable.

> As a mix proposal, it would be more interesting if a new URL was
> generated everytime the user identifies (with login/password). More
> interesting again, it could be generated client side in Javascript using
> a formula like "HASH(HASH(password) + challenge)" where the challenge is
> a temporary value generated by the server for this very session (thus
> with an expiration time). Which means:
> - the URL is temporary (it expires with the challenge)
> - this URL does not need to be recorded anywhere on the client since
> it's generated at every new login
> - in plain non-encrypted HTTPS, the data which goes over the wire only
> gives temporary access to the resource

When I attend DefCon, I am always amazed that people are surprised by
the Wall of Sheep, people who know that network snooping is possible.
I guess you just have to experience the efficiency of live network
snooping in order to truly appreciate it.

With the rise of ubiquitous WiFi, passing secrets, even temporary
ones, over the network in the clear is asking for trouble. Your 15
minute session timeout is an eon on the timescale of a script watching
the network for your protocol and exploiting it on the fly.

SSL has finally come into a somewhat reasonable price range. We should
go ahead and exploit it. We don't need to mess around with dodgy
timeout based designs.

Thanks again for the questions.

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