Can an IdP mask as one of its user?

[Denis Washington]

Hi,

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?

Regards,
Denis

[Benjamin Smedberg]

On 11/14/2012 1:23 PM, Denis Washington wrote:
> Hi,
>
> 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.

--BDS

[Dan Callahan]

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.

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?

Thanks for the feedback and questions,
-Callahad

[Denis Washington]

Am 14.11.2012 20:15, schrieb Dan Callahan:
> 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.)

Denis

[Daniel Mills]

On Nov 14, 2012, at 11:20 AM, Dan Callahan <dcal...@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

Dan

[Daniel Mills]

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.

Banks do this today, for example.

Dan