

Don’t Use Mozilla Persona to Secure High-Value Data - zobzu
http://benjamin.smedbergs.us/blog/2014-02-11/dont-use-mozilla-persona-to-secure-high-value-data/

======
callahad
Hi, I hack on Persona at Mozilla. Persona is not a panacea, but this post is
disingenuous.

Benjamin is concerned about user impersonation by identity (email) providers.

1\. The _identical_ risk of silent impersonation is present with any OpenID or
OAuth-based system.

2\. With password-based systems, a malicious provider could also intercept
reset emails, creating similar risk. Benjamin notes that "a user will be aware
of the attack then next time they try to login," but that's a poor mitigation,
since the attacker has already gained access. Benjamin agrees: "On
bugzilla.mozilla.org, we disabled password reset emails for users with access
to security bugs."

If you're operating under the same constraints as Benjamin, then I agree:
Persona alone is not sufficient. Nor is _any_ other normal authentication
system.

~~~
StavrosK
Since each IdP has a private key, couldn't they request "pinning" it? So, for
example, I can ask my IdP to say "I will be the IdP for this user for at least
a year, if you get a different signature within this year, it's an impostor".

Each client would have to cache the ID specifically for every user, but that
doesn't seem too bad for the extra security it gives. Alternately, the user
themselves could send the IdP ID to the authenticating site and the site can
check that they match, thus detecting any foul play.

Please correct me if I'm talking out of my ass, it's been a while since I
implemented an IdP.

~~~
jessaustin
Smedberg is talking about a situation in which the IdP itself isn't to be
trusted: it impersonates the user to the RP.

~~~
StavrosK
I was talking about the ".well-known/browserid file being changed to something
else" attack, #2.

~~~
jessaustin
Ah, sorry for the confusion then. I have to say, an attacker who can change
random files on the server can do all sorts of naughty things. Serve evil
javascript libs? Change server configuration? Insert her own TLS cert? Check,
check, check. Why would .well-known stuff be any different?

For those who do have problem with this, I guess I see why they want DNS SRV,
but I can also see why the "plain DNS" complaints sidetracked this
functionality.

~~~
StavrosK
Well, it's not necessarily that. For example, my website serves an authority
delegation file ([https://stavros.io/.well-
known/browserid](https://stavros.io/.well-known/browserid)) which I _really_
don't want an attacker to mess with. Serving JS libs/changing the config/etc
wouldn't get them anywhere, unless they could change that single file.

Since there are some ways to protect from that (I think the two I proposed
above are reasonable), Mozilla probably should think about implementing it.

------
fournm
I'm sorry, I might just be misunderstanding so please correct me if I'm wrong
but...

The main vulnerability he talks about is if a major provider were to be hacked
and have their file replaced (or go rogue, entirely). In either case, is _any_
login system that doesn't use two factor authentication and allows for
password resets via email really going to do any better?

Edit: I realize he points out that 2 factor auth really is the only solution
here, just, it seems like the criticism applies much more widely than just
against Persona.

~~~
drdaeman
The main problem with Persona (and OpenID and OAuth) is that you don't own
your identity, by design. The identity is completely managed by provider, so
anything that uses Persona is inherently prone to all sorts of identity
provider abuse.

Analogy: you don't have any keys to your safe deposit box at bank, but a
warden may open it for you after a phone call to your landlord, who'd assert
your identity. The obvious question is why we need a landlord in this
scenario.

Unfortunately, gpgAuth is practically dead and WebID WG had no progress for
two years.

~~~
callahad
It's a delicate balance between security and usability. Zooko's triangle
applies here. To wit, GPG and client-side SSL certificates have pretty ideal
security properties, but impose upon the user to manage storing and syncing
key material between devices.

[http://en.wikipedia.org/wiki/Zooko%27s_triangle](http://en.wikipedia.org/wiki/Zooko%27s_triangle)

 _EDIT:_ Heh. Actually Zooko's doesn't _fully_ apply here, but it's still a
fun read. Thanks Perseids and drdaeman. :)

~~~
Perseids
Zooko's triangle is about secure name systems like DNSSec or Namecoin, not
about user logins.

~~~
dllthomas
According to the wiki page, it's _" a conjecture for any system for giving
names to participants in a network protocol"_.

"Nicknames users choose for themselves" is listed as one example point in the
space.

~~~
drdaeman
From what I've seen Persona is mostly advertised as solving problem with
credentials (passwords, OpenIDs, etc.), not nicknames.

Actually, I don't think there's anything wrong with nicknames and their lack
of global uniqueness. Moreover, I believe it's a good thing.

~~~
dllthomas
Persona solves the problem of uniquely naming you to the site, on the
assumption that you already have a unique email. There's more pieces here with
their own issues, but I _think_ Zooko's triangle is still relevant.

 _" Actually, I don't think there's anything wrong with nicknames and their
lack of global uniqueness. Moreover, I believe it's a good thing."_

That depends entirely on the applications you're intending to put them to...

~~~
drdaeman
> the problem of uniquely naming you to the site

Ahem. Did we (consumers, not site owners) really have this problem, to begin
with?

~~~
dllthomas
That's irrelevant to whether Zooko's triangle applies, which was all I was
weighing in on.

That said, yes, consumers totally have this problem. We encounter it visibly
every time a username we want is taken when we try to sign up for a site. The
effectiveness with which Personal eliminates it entirely, ameliorates it, or
merely pushes it off to other parts of the system depends on other details of
the service in question.

It's also not the only problem Persona purports to solve, simply the relevant
one.

------
natrius
A more PR-friendly headline would be, "Use Two-Factor Authentication to Secure
High-Value Data." Persona is not the problem.

~~~
StavrosK
You mean two-factor auth on the IdP, or on the site itself? The former
wouldn't solve the problem, but the latter would.

~~~
natrius
You're correct. The latter.

------
wtbob
It seems to me that the issue with respect to the .well-known/browserid which
he raises is itself an issue with the CA system; the assumptions are a) that
the key serving the site is verified by a trusted CA and b) that the key is
serving the correct file. In fact, it's quite possible that a trusted CA is
compromised, and it's even possible that the key has been misled into serving
(and authenticating) the wrong file.

In short, we're entrusting every single CA in the world with the login of
every single user in the world.

That doesn't seem terribly good to me.

A better system, IMHO, would involve offline keys for each identity provider;
these keys would each sign an online key (or online keys) which would be used
to authenticate the users. Each relying party would have to make a decision on
how to handle hitherto-unseen keys (TOFUPOP backed up by SSL is, while
imperfect, no indefensible).

TOFUPOP would protect against bad-faith CAs, and offline long-term keys would
enable key mobility. Note that with a properly-specified certificate calculus,
the offline key could authorise its own backups...

------
dllthomas
I think the reason Persona is singled out here is simply that this guy is
commenting from Mozilla.

~~~
jessaustin
Yeah it's cool that they tolerate a diversity of thought on core issues.

~~~
sabbatic13
It is, but there's also some historical friction between the people who hack
on gecko (like smedberg) and the people who hack on the services that tie into
the browser, so sometimes it's diversity of opinion, and sometimes it's
tribalism.

In this case, I'd be more inclined to listen to the commenter on his blog,
Monica Chew. She's the security/privacy developer. Smedberg is a stone-cold
genius who brought such things as Electronlysis to FFx, but he isn't blogging
as a security expert. So, it's an informed and intelligent opinion, but it's
not quite an expert one and the wording may be somewhat colored by the long-
standing tradition of Platform Engineering pointing out where Services
Development is getting it wrong.. IMHO at least.

~~~
jessaustin
Thanks for the interesting background on the personalities.

Smedberg isn't _wrong_ about the specific set of circumstances he cites: if an
IdP (or someone who controls one, in whatever fashion) knows an RP to which a
particular user auths, and wants to fool them both, it can. I think at this
point we're supposed to advocate "defense in depth" and observe that there is
nothing to prevent layering other mechanisms alongside Persona. For example:
client certs, tokens, OTP systems, old-fashioned HTTP-auth, etc. For that
matter, you could require the use of more than one IdP! (Not sure if the
current javascript lib would tolerate this, but one could certainly modify it
to do so... could this get on the roadmap for the rumored browser
integration?)

I think most IdPs people are likely to use are strongly incentivized not to
screw this up, but if it becomes an issue then some IdPs might be able to
create value by being more trusted or auditable.

