Hi! I am exhuming this thread after some discussions in meatspace with one developer of Mozilla Persona. Mike Perry: > Thus spake NoName (antispam06@xxxxxxx): > > 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@xxxxxxxxxxxxxx>
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-talk mailing list tor-talk@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk