Don’t Use Mozilla Persona to Secure High-Value Data
benjamin.smedbergs.us
benjamin.smedbergs.us
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.
He could also intercept the login attempts (e.g. webmail login form => the password is typically sent in plain text to the server [regardless of transport security]), the user will never notice.
I don't understand what you mean. If the form submit is over https, isn't the password neccesarily (not just typically, but always) _not_ sent in plain text to the server, but sent encrypted via SSL/TLS cause that's the whole point of https?
https is transport security. The data goes over the 'net in encrypted form, but the endpoint will get it in plain text (same as the contents of the html page with the form, which your browser sees as plain text, even though you access it over https). Therefore, an attacker who operates the server (or has compromised it), can just grab the plaintext passwords as you log in over https.
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.
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.
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.
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.
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.
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. :)
"Nicknames users choose for themselves" is listed as one example point in the space.
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.
"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...
Ahem. Did we (consumers, not site owners) really have this problem, to begin with?
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.
Certificates fit into Zooko's triangle just fine. They're decentralized and secure, but those keys don't mean anything to humans. Is lack of human-meaningful global identifier (like an email address) a problem? I believe we're pretty much fine with choosing a name (usually, a pseudonym) when registering with a service. Actually, I believe we even enjoy an ability to name ourselves as we see fit, and there's no real need for human-meaningful global identity identifiers. Or I'm wrong on this matter?
> impose upon the user to manage storing and syncing key material between devices
I don't see any serious problems with storing keys. Could you explain this a bit more? Did you mean that keystores are less secure than a browser logged into Persona/email account? If so, TPMs/HSMs are also getting more and more widespread (although rarely supported and used in practice, which is regrettable) and can further improve situation with secure key storage.
Password sync can be made both usable and reasonably secure (proven both by both Mozilla and Chrome), why key sync can't? One can sync a single key over multiple devices using some kind of key escrow, or trade a bit of convenience for security with the necessity for one-time initial device setup (signing device key with a master key).
I'm no security expert, but I think the most problematic part with certificate-based credentials is not syncing or storage but revocation of compromised credentials. But it's the same with passwords, certificates, emails and every other credential system out there.
If you meant that Persona consumer site can consider Persona to be not an identity but a credential, and ask me for a secondary one (2FA), then you're right. But the question on why need a landlord as a part of authentication protocol remains open.
But can't we do something similar for every possible system? By controlling my computer's OS, Apple could in principle have a copy of my GPG keys and passwords right now. Ok, I'll use Linux... but do I need to worry about Intel recording the same data somehow? The point is, I'm constantly being forced to store my credentials in someone else's hands.
An AVR (like Arduino) would suffice without much need to trust hardware vendor. It has no communication channels except for the one you define (and you can and should define quite a restricted one) and not much die space (and too low cost) to have a backdoor to begin with. (And really paranoid ones could always go with TTL.)
The only serious problems are cryptographer-vetted RSA implementation that would fit in an AVR and writing a PKCS#11 driver for such HSM.
Yeah, this is totally on tinfoil-hat-grade paranoid side of things, but a CPU-level backdoors are not far from that.
(I'm tempted to say people don't care, but I agree that they mostly don't want other people accessing their accounts)
For those who don't it shouldn't matter whatever they're using (some third party account or a personal certificate or a saved password) to authenticate. They click "login" and they get what they want.
For a minority of those who do, leasing their identity from a third party probably don't looks like a good idea.
(I actually think the use of an email address in persona is genius, anybody who wanted valid email addresses would never consume something like OpenID)
Which I think is an important property: if you can come up with a better or more secure IdP experience, you can enter the ecosystem without the ecosystem (that is, Relying Parties) having to change anything. That's a huge win over the current state of login.
All three work alike if you run your own IdP. If you are yourself OAuth provider then you can control your own identity. If you don't trust Mozilla being your IdP (which you probably shouldn't if you are paranoid), you run your own IdP. Am I wrong?
With your own server you'll have to lease your identity from the domain registrar. In contrast, with certificate-based credentials you actually possess the keypair.
No clue what point this post was trying to make
And every CA in the world.
And trust that the identity provider is always competent (i.e., that the .well-known/browserid file is never compromised).
Which isn't really true of usernames & passwords--at least that way a mistake at my mail provider doesn't automatically expose my banking account to risk.
I am not getting your point about PGP. Using PGP as Identity authentication? Wouldn't it just be the same as running your own IdP?
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...
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.
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.