[tor-talk] Mozilla Persona and Tor

Lunar lunar at torproject.org
Fri Jul 12 13:17:01 UTC 2013


Hi!

I am exhuming this thread after some discussions in meatspace with one
developer of Mozilla Persona.

Mike Perry:
> Thus spake NoName (antispam06 at sent.at):
> > Today I went to a site that requires registration. This is not the
> > New York Times, so no need of Bug Me Not. It asks for FB (out of the
> > question), MSN (out of the question), Google (limited number of Tor
> > accounts) or Persona. I would not sacrifice the Google account.
> 
> I'm glad that it is seeing use, but I'm not sure exactly how, since
> navigator.id (where its browser-side API is supposed to live) doesn't
> exist in any browsers I have installed, including Firefox 19.

That API is currently provided by a JavaScript library. See “Step 1” of
the Quick Setup page:
<https://developer.mozilla.org/en-US/docs/Mozilla/Persona/Quick_Setup>

> From my perspective the most important properties of Persona are:
> 
> 1. In theory, the identity provider does not discover the sites that you
> visit. It merely issues a signed statement that your browser stores to
> later present to websites. If this property holds, it's quite awesome.
> 
> 2. Sites that you visit do not get to inspect which identity statements
> you have installed. The user is prompted to send the site either zero or
> one of their potentially many signed identity statements. This is also
> awesome.
> 
> 3. From my read of the spec, there also seems to be no technical reason
> why the identity provider can't be kept offline -- except for the fact
> that they recommend user certificate expiration times on the order of 24
> hours for some reason (which introduces potentially serious privacy
> problems. See below).

The technical reason is key rollovers. There is currently no way for
identity providers to advertise a new key. In case of compromise of
their private key, identity providers will have to wait for sites to
fetch a new one from the `.well-known/browserid` descriptor. The
expiration time is there to minimize the delay.

> The first two properties make me think that if the user is allowing disk
> history records, there should be no remaining content-facing privacy
> reasons that prevent these certs from being stored and persisting
> forever (or until the user deletes them). That is also pretty awesome.
> 
> 
> However, the following general privacy issues seem to exist with the
> specific deployment and implementation that the spec seems to suggest:
> 
> 0. Can sites determine if I have at least one identity statement? Do the
> APIs behave differently in this case? Perhaps this is why I don't have
> navigator.id, for example? If so, that's a fingerprinting bit. From the
> point of view of the website, the APIs should behave identically
> regardless of how many certificates I have, even if I have zero. (Note
> this doesn't mean that what the user actually sees has to be the same in
> that case).

Clicking the “Cancel” button or having zero certificates will send the
same result. So sites should not be able to determine if you have at
zero, one or more identity statements. (Except maybe by timing…)

> 1. Why do users have to get their certs re-signed by the Identity
> Provider every 24 hours? This means the Identity Provider gets to know
> which of their users are using the web on a given day, and from which IP
> addresses. Worse, the specs seem to suggest this re-signing should
> happen transparently in the background without user input.

(I am not sure I totally got this part in full.)
The idea is that once properly identified, a website would set a session
cookie as usual. If the session cookie is not expired but the cert
is, usage of the site will not be advertised to the identity provider.
If the session cookie is expired but the cert is not, login should
effectively happen without user interaction. If both are expired,
users will be prompted to authenticate with their identity provider as
usual.

> That means by installing an identity cert, you are actually handing
> over your daily IP address history to your Identity Provider,
> regardless of how frequently you really want to interact with them.

If your identity provider is your email provider, it is likely that you
will check your email too. Using Tor should be enough prevent them to
know one's location.

> 2. What authenticates an Identity Provider to a website? If their IdP
> certs have to be signed by the CA model, that kinda sucks, but at least
> authentication could still be done offline. However, if their certs have
> to be fetched by the authenticating site over CA-authenticated HTTPS,
> that *really* sucks (because it damages privacy property #1 - identity
> providers would know if at least one of their users visited a site). It
> would be nice to have both options.

Currently, the IdP descriptors have to be fetched by the authenticating
websites over CA-authenticated HTTPS. People working on Persona are
aware that this is far from ideal from a security point of view and
already had to patch several Persona implementation to make sure the
certs were properly verified.

Regarding privacy, the authenticating website does not announce itself
to the identity provider. It is only the IP address used to retrieve the
descriptor that could be used to identify the website. This means that
teaching websites to retrieve the IdP descriptors through Tor would
prevent IdP from knowing that these sites have been visited by one of
their users.

Another option would be to retrieve the IdP descriptors at regular
interval using cron or another mecanism. IdP would then have a constant
trace, with or without users logging in.


Hope that answers some questions. We can probably get other answers now
that contact has been made. :)

-- 
Lunar                                             <lunar at torproject.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20130712/4575c5e3/attachment.sig>


More information about the tor-talk mailing list