W3C home > Mailing lists > Public > public-xg-webid@w3.org > July 2011

Re: WebID, BrowserID and NSTIC

From: Stéphane Corlosquet <scorlosquet@gmail.com>
Date: Mon, 25 Jul 2011 17:26:24 -0400
Message-ID: <CAGR+nnEtjd1S_aLOBscAvA67UvYPZ5cE33yR+DLE5PLeWELW=A@mail.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>
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.
Received on Monday, 25 July 2011 21:27:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:06:25 UTC