Google 'Safe Browsing' vs. RESTful authorization Re: [p2p-hackers] Re: [rest-discuss] Re: RESTful authorization

[Gordon Mohr]

I like Tyler's notion of SSL-passed 'capability URLs', and had
occasion to think about them again when reading the following:

   Two Things That Bother Me About Google’s New Firefox Extension
   http://www.oreillynet.com/pub/wlg/8760

   "1) Every request is transmitted to Google over HTTP, i.e. in
   clear-text. This is not good. Here is why: Consider a web
   application that uses SSL to encrypt the session. If this web
   application were to submit private information about you via a
   GET request (i.e in the URL, such as a credit card number),
   this will now be transmitted to
   http://www.google.com/safebrowsing/lookup in clear-text, allowing
   someone on your network segment, or any router in between yourself
   and google.com to sniff the information off the wire."

Asking a trusted third party their opinion of an URL seems a
reasonable anti-phishing measure. But if that "trusted" third
party is careless in its handling of HTTPS URLs, as it
appears Google has been in this design, the prerequisite
URL secrecy required for capability URLs will be often and
casually violated.

Of course, any security measure can be thwarted with sufficient
carelessness, and in this case the onus should be on Google to
fix this oversight, and respect the privacy of HTTPS URL requests.

But it's been 2 weeks since this problem was highlighted, and
it remains unfixed and mostly undiscussed. That suggests to me
that people's expectations of HTTPS URL secrecy -- and of the
standards that toolbar/extension makers like Google should be
held to in protecting user secrets -- are pretty low. Perhaps
so low that capability URLs would only be usable by the
hyper-conscientious, who generally do fine under any system.

- Gordon

Tyler Close wrote:
> 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
> _______________________________________________
> p2p-hackers mailing list
> p2p-hackers at zgp.org
> http://zgp.org/mailman/listinfo/p2p-hackers
> _______________________________________________
> Here is a web page listing P2P Conferences:
> http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences
>