[liberationtech] Announcing a privacy preserving authentication protocol

[Steve Weis]

At its core of this proposal, sites run their own CAs and users install
site-specific client-side certificates. Many organizations have been doing
this for years. For example, MIT: http://ist.mit.edu/certificates .

I like client certificates as an additional factor in general, but user
enrollment across multiple devices, browser and platform compatibility, and
revocation of lost devices are a pain. I think the biggest adoption of
client certificates has been in large organizations with managed devices
and support staff.

Incidentally, there have been attacks to use client certificates as
persistent "supercookies" to track users, but I don't know the current
state of how browsers handle this. Here's an old PoC:
http://0x90.eu/ff_tls_poc.html . Firefox 4 at least prompts you before
dumping your cert to https://www.apache-ssl.org/cgi/cert-export .

The author also makes claims this could prevent cross-site scripting with a
"cryptographic same origin policy". I don't buy that, since XSS attacks
could still be served from sites with valid certificates. If someone has a
vulnerable web app, it's still going to be vulnerable.

Finally, this proposal requires changes on server-side authentication and
potentially in browsers themselves. Sites don't typically change their
authentication system unless it drives user adoption (e.g. OpenID or
Facebook Connect) or is needed for security (e.g. 2-factor auth). I don't
see any incentives for adoption here.



On Tue, Mar 12, 2013 at 4:31 PM, Kyle Maxwell <kylem at xwell.org> wrote:

> I appreciate the intention, but I see a lot of problems here. Without
> doing an exhaustive analysis:
>
> A. This doesn't eliminate phishing because users will still enter
> their credentials at a site that doesn't actually match the one where
> the cert was previously signed. Otherwise, existing HTTPS controls
> would already protect them.
>
> B. What zone would contain user keys for DNSSEC?
>
> C. Your message transport protocol seems a little unclear - could you
> walk through it?
>
> There are more issues here, but at a minimum I feel like it doesn't
> adequately address a broad enough threat model.
>
> On Tue, Mar 12, 2013 at 4:08 PM, Guido Witmond <guido at witmond.nl> wrote:
> > Ladies and Gentlemen,
> >
> >
> > I've long disliked the direction the internet headed with regards to
> > privacy. Or it's total disregard of it.
> >
> > I've come up with a novel architecture of existing old and recent
> > cryptographic tools that offers a substantial improvement in security and
> > privacy. I call it Eccentric Authentication.
> >
> > Unlike the current CA-system that requires people to trust them to gain
> > security, my protocol turns that upside down. Security is what the
> protocol
> > provides. Trust is what people gain by using the system.
> >
> > The protocol is mostly compatible with the current internet as we know
> it.
> > And it prevents most phishing attacks for free.
> >
> > I have the hope that this protocol can shift the balance of security and
> > privacy a bit back towards the people.
> >
> > I've written a technical description at [1]. I hope it makes things a bit
> > clear. Feel free to comment.
> >
> > With regards. Guido Witmond.
> >
> > 1: http://witmond.nl/ecca/eccentric-authentication.html
> > --
> > Too many emails? Unsubscribe, change to digest, or change password by
> > emailing moderator at companys at stanford.edu or changing your settings at
> > https://mailman.stanford.edu/mailman/listinfo/liberationtech
> --
> Too many emails? Unsubscribe, change to digest, or change password by
> emailing moderator at companys at stanford.edu or changing your settings at
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20130312/76943d2a/attachment.html>