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.
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.
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.
Well, it's not necessarily that. For example, my website serves an authority delegation file (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.
> 2. With password-based systems, a malicious provider could also intercept reset emails,
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.
> webmail login form => the password is typically sent in plain text to the server [regardless of transport security
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?
> isn't the password neccesarily [...] _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.
I think the point is that if your email provider is hacked or malicious, your email password is hacked, but that's really only a problem if you use the same password on multiple sites. Don't do that.
If your email is hacked/malicious, and that's where your password reset requests from twitter, facebook, HN etc. are sent, it doesn't matter whether you reuse passwords or not; the attacker has the power to change them.
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.
A slightly less overloaded summary might be "users must trust their identity provider", which is true of every authentication scheme I'm aware of except for perhaps PGP, which itself is a usability nightmare for 99% of the planet
> A slightly less overloaded summary might be "users must trust their identity provider"
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.
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.
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.
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.
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...
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.
If I understand Persona correctly, you are entirely welcome to have the bank keep your cell phone number on file instead of your landlord's number. You only need to rely on a landlord if you don't want to go to the trouble of carrying a phone of your own.
If you meant I can setup my own Persona auth server on my "own" domain, then it's just that my landlord is my domain registrar. It's probably less likely that one would be stripped off "their" domain name than of "their" email account, but the problem still remains. The fundamental principles don't change in this scenario - none of credentials are in your direct possession.
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.
Ah, I see your point now: my cell phone carrier can still trick the bank into unlocking my safe deposit box.
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.
Well, not really. You could build your own HSM, that would store your keys and sign things for you. Obviously, only with your physical permission (a button press or even a PIN entry).
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.
People don't want to understand or care about identity and authentication. In that context, a nice thing about persona is that it makes things easier without really introducing any new problems (email is already a control point).
(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.
On the other hand, those people can mostly run their own IdP, so they depend on fewer/more trustable parties (just the DNS registrar, and their colo?), but still get the same user experience.
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.
Sure, but if the question is between medium value sites leaning on sending emails to control accounts and medium value sites leaning on persona for identity assertions, there aren't really any new issues, and all those people get rid of some passwords. It doesn't solve your problems, but it doesn't make them significantly worse and it is a step forward for most people.
(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)
The main problem with Persona (and OpenID and OAuth) is that you don't own your identity, by design
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?
You can't really own an IdP as you can't truly own a domain name, by which IdPs are identified in OpenID/OAuth/Persona protocols.
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.
It's more than just 2-factor, your site has to control the second factor. E.g., even if you're using Google OAuth and requiring folks to have 2FA turned on, Google still effectively controls both of the factors.
I don't really agree Persona is trying to sell a silver bullet. If you review the site here, I don't see anything that says Persona is great for all use cases:
I meant that strictly in the context of the article saying that "I have seen a trend recently of people within Mozilla insisting that we should use Persona for all logins."
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...
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.
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.
Now that Firefox Accounts is being used in Mozilla properties rather than Persona I'd expect more downplaying of Persona to come from Mozilla, including employees like OP. Is Persona still being developed at Mozilla?
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.