Re: WebID, BrowserID and NSTIC

Steph,

> Cookies used in HTTPS should be set to secure cookies so that the
> browser does not send them unencrypted, thus avoiding HTTPS Cookie
> Hijacking. There were some exploits circulating in the past but most
> applications have been fixed by now. So out of the three types of
> attacks, the transmission one is easy to avoid. Server: if a server is
> compromised, it is already game over (nevermind cookies). The last one
> is the browser (less likelihood), where cookies + public keys could be
> stolen.

There's been a whole sequence of cookie exploits.  Hopefully they have
all been fixed, and hopefully the sequence has ended and there will be
no more exploits in the future.  On the other I haven't heard of
any private key exploits; have there been any?

Regarding attacks against the server: saying "game over" is an
oversimplification.  For example there could be an attack whose effect
is precisely to leak the cookie.  An SQL injection  attack might have that
effect.  And remember the very recent Firesheep attack againt
Facebook, which achieved user impersonation by capturing a cookie,
exploiting a cookie management vulnerability.

Let me emphasize that I'm not saying cookies are inherently insecure.
I'm just saying that, from a point of view of defense-in-depth, private
keys provide better security than cookies.

Francisco

Francisco Corella, PhD
Founder & CEO, Pomcor
Twitter: @fcorella
Blog: http://pomcor.com/blog/
Web site: http://pomcor.com


>________________________________
>From: Stéphane Corlosquet <scorlosquet@gmail.com>
>To: Francisco Corella <fcorella@pomcor.com>
>Cc: Melvin Carvalho <melvincarvalho@gmail.com>; Henry Story <henry.story@bblfish.net>; WebID XG <public-xg-webid@w3.org>; Karen Lewison <kplewison@pomcor.com>
>Sent: Monday, July 25, 2011 2:26 PM
>Subject: Re: WebID, BrowserID and NSTIC
>
>
>Hi Francisco,
>
>
>On Mon, Jul 25, 2011 at 4:50 PM, Francisco Corella <fcorella@pomcor.com> wrote:
>
> <snip>
> 
>> Though I wonder how different this
>>> is from a cookie or HTML5 browser data storage?
>>
>>It's functionally equivalent to a cookie or HTML5 browser data storage
>>(or Flash data storage), but more secure.  A cookie is a shared
>>secret, you have to send it to the relying party.  If you send it over
>>a TLS connection and nothing goes wrong, that's OK.  But if something
>>goes wrong due, e.g., to a vulnerability, and an attacker gets the
>>cookie, then the attacker can impersonate.  By contrast, the private
>>key associated with a
 certificate stays in the browser.  Sure, the
>>browser could be compromised, but that's less likely.  Another way to
>>put it: the attack surface against a cookie includes browser, server,
>>and transmission, whereas the attack surface against a private key
>>includes the browser only.
>
>
>Cookies used in HTTPS should be set to secure cookies so that the browser does not send them unencrypted, thus avoiding HTTPS Cookie Hijacking. There were some exploits circulating in the past but most applications have been fixed by now. So out of the three types of attacks, the transmission one is easy to avoid. Server: if a server is compromised, it is already game over (nevermind cookies). The last one is the browser (less likelihood), where cookies + public keys could be stolen.
>
>
>Steph.
>
>