After a close look at the Persona protocol today, it seems as if a system administrator with access to the private key of an IdP - say, eyedee.me - could use this to sign certificates for arbitrary @eyedee.me accounts for him/herself and use them with all RP's without being caught.
Is there any measure against this in the protocol that I overlooked? Is it even possible to avoid this weakness? Or do you just have to trust your IdP to not do this?
> After a close look at the Persona protocol today, it seems as if a > system administrator with access to the private key of an IdP - say, > eyedee.me - could use this to sign certificates for arbitrary > @eyedee.me accounts for him/herself and use them with all RP's without > being caught.
Yeah, this is part of the design of the system. If eyedee.me is vouching for the identity of user, then you have to trust them to do it correctly.
The thinking behind "why this is ok" is that a provider can *already* forge your identity on most sites by sending a password reset email and reading it (because they have access to your email). I'm not convinced that this is a good argument, because the user would at least know that something bad happened the next time they tried to log in and the password was reset and didn't work. In the BrowserID scheme, the user might not know at all.
> Is there any measure against this in the protocol that I overlooked? Is
> it even possible to avoid this weakness? Or do you just have to trust
> your IdP to not do this?
The protocol expects you to trust your email provider. After all, by virtue of hosting your email with them, you're already trusting them with an enormous amount of private information.
Today, if your email provider wanted to own you, they could own you. Persona doesn't change that either way.
Do you have any ideas for how we could provide IdP-independent security and reduce that need for trust in a way that's still completely decentralized?
> On 11/14/12 12:23 PM, Denis Washington wrote:
>> Is there any measure against this in the protocol that I overlooked? Is
>> it even possible to avoid this weakness? Or do you just have to trust
>> your IdP to not do this?
> The protocol expects you to trust your email provider. After all, by
> virtue of hosting your email with them, you're already trusting them
> with an enormous amount of private information.
> Today, if your email provider wanted to own you, they could own you.
> Persona doesn't change that either way.
Hm, you're absolutely right there.
> Do you have any ideas for how we could provide IdP-independent security
> and reduce that need for trust in a way that's still completely
> decentralized?
The only thing that might help a bit were the possibility to tell sites that they should only trust signatures from certain devices (that is, certain private keys). That way, a user could trade in some convenience for being sure that any forged certificates from the IdP would fail. (Assuming, naturally, that the IdP's provisioning JS code has no way to get to the private key generated by navigator.id.genKeyPair.)
On Nov 14, 2012, at 11:20 AM, Dan Callahan <dcalla...@mozilla.com> wrote:
> On 11/14/12 12:23 PM, Denis Washington wrote:
>> Is there any measure against this in the protocol that I overlooked? Is
>> it even possible to avoid this weakness? Or do you just have to trust
>> your IdP to not do this?
> The protocol expects you to trust your email provider. After all, by virtue of hosting your email with them, you're already trusting them with an enormous amount of private information.
> Today, if your email provider wanted to own you, they could own you. Persona doesn't change that either way.
To put this in a bit of a different context -- think about more "traditional" providers of identity: e.g. think about a DMV-issued driver's license, or a central government-issued passport.
It's not a straight parallel, of course. For one thing, you can choose who your email provider is, whereas you don't get to choose your DMV (not without moving, anyway). But the point of federated identity is the same: whoever provides the identity can impersonate the identities, since it can mint the same identities unto itself/anyone of its choosing.
On the point that with a per-site password scheme the user would be alerted:
a) many users would simply assume they forgot their password, reset it, and be none the wiser
b) the problems with passwords at each site greatly outweigh this benefit, and
c) if a site wants to require a second factor independent from the IdP (a password or something else), it can still do so
On Nov 14, 2012, at 11:39 AM, Denis Washington <den...@online.de> wrote:
> The only thing that might help a bit were the possibility to tell sites that they should only trust signatures from certain devices (that is, certain private keys). That way, a user could trade in some convenience for being sure that any forged certificates from the IdP would fail. (Assuming, naturally, that the IdP's provisioning JS code has no way to get to the private key generated by navigator.id.genKeyPair.)
Persona keys are short-lived, but sites could cookie devices and use that as an additional auth factor. What to do when it encounters a new device depends on the app, but it could (for example) alert the user via a backup email/phone #, or require some kind of additional authentication.
