Don’t Use Mozilla Persona to Secure High-Value Data
Mozilla Persona (formerly called Browser ID) is a login system that Mozilla has developed to make it better for users to sign in at sites without having to remember passwords. But I have seen a trend recently of people within Mozilla insisting that we should use Persona for all logins. This is a mistake: the security properties of Persona are simply not good enough to secure high-value data such as the Mozilla security bug database, user crash dumps, or other high-value information.
The chain of trust in Persona has several attack points:
The Public Key: HTTPS Fetch
When the user submits a login “assertion”, the website (Relying Party or RP) fetches the public key of the email provider (Identity Provider or IdP) using HTTPS. For instance, when I log in as benjamin@smedbergs.us, the site I’m logging into will fetch https://smedbergs.us/.well-known/browserid. This relies on the public key and CA infrastructure of the internet. Attacking this part of the chain is hard because it’s the network connection between two servers. This doesn’t appear to be a significant risk factor to me except for perhaps some state actors.
The Public Key: Attacking the IdP HTTPS Server
Attacking the email provider’s web server, on the other hand, becomes a very high value proposition. If an attacker can replace the .well-known/browserid file on a major email provider (gmail, yahoo, etc) they have the ability to impersonate every user of that service. This puts a huge responsibility on email providers to monitor and secure their HTTPS site, which may not typically be part of their email system at all. It is likely that this kind of intrusion will cause signin problems across multiple users and will be detected, but there is no guarantee that individual users will be aware of the compromise of their accounts.
Signing: Accessing the IdP Signing System
Persona email providers can silently impersonate any of their users just by the nature of the protocol. This opens the door to silent identity attacks by anyone who can access the private key of the identity/email provider. This can either be subverting the signing server, or by using legal means such as subpoenas or national security letters. In these cases, the account compromise is almost completely undetectable by either the user or the RP.
What About Password-Reset Emails?
One common defense of Persona is that email providers already have access to users account via password-reset emails. This is partly true, but it ignores an essential property of these emails: when a password is reset, a user will be aware of the attack then next time they try to login. Being unable to login will likely trigger a cautious user to review the details of their account or ask for an audit. Attacks against the IdP, on the other hand, are silent and are not as likely to trigger alarm bells.
Who Should Use Persona?
Persona is a great system for the multitude of lower-value accounts people keep on the internet. Persona is the perfect solution for the Mozilla Status Board. I wish the UI were better and built into the browser: the current UI that requires JS, shim libraries, and popup windows; it is not a great experience. But the tradeoff for not having to store and handle passwords on the server is worth that small amount of pain.
For any site with high-value data, Persona is not a good choice. On bugzilla.mozilla.org, we disabled password reset emails for users with access to security bugs. This decision indicates that persona should also be considered an unacceptable security risk for these users. Persona as a protocol doesn’t have the right security properties.
It would be very interesting to combine Persona with some other authentication system such as client certificates or a two-factor system. This would allow most users to use the simple login system, while providing extra security properties when users start to access high-value resources.
In the meantime, Mozilla should be careful how it promotes and uses Persona; it’s not a universal solution and we should be careful not to bill it as one.
February 11th, 2014 at 2:15 pm
These attacks seem to reduce to: Persona is as secure as its email verification protocol, which relies on the security of the underlying mail servers. I’d agree with that, and also add that every web service today that relies on email for password resets (nearly all of them) is in the same boat. So is it better or worse that some of them want to outsource authentication?
February 11th, 2014 at 2:57 pm
Monica, it’s disappointing you seem to have not read the article for before hastily posting your criticism. This part renders your entire comment null:
“One common defense of Persona is that email providers already have access to users account via password-reset emails. This is partly true, but it ignores an essential property of these emails: when a password is reset, a user will be aware of the attack then next time they try to login. Being unable to login will likely trigger a cautious user to review the details of their account or ask for an audit. Attacks against the IdP, on the other hand, are silent and are not as likely to trigger alarm bells.”
February 11th, 2014 at 3:12 pm
“On bugzilla.mozilla.org, we disabled password reset emails for users with access to security bugs.”
We did? Bug number?
I think Persona has at least the _potential_ to be more secure, for people who own their own domains. If you are logging in as benjamin at smedbergs dot us, you can have whatever solid auth you want on that Persona interaction – 2-factor, whatever. In this scenario, your hole 3 is irrelevant – you can already impersonate yourself.
Gerv
February 11th, 2014 at 4:22 pm
> This relies on the public key and CA infrastructure of the internet. Attacking this part of the chain is hard because it’s the network connection between two servers. This doesn’t appear to be a significant risk factor to me except for perhaps some state actors.
It’s worth noting that many frameworks do not validate SSL certificates by default. You still need to be able to intercept the traffic, though.
February 11th, 2014 at 6:52 pm
Gerv, I don’t know a bug number (I expect it’s not public), but I do know that the last time I tried a password reset I got some sort or email or message stating that password reset was disabled for my account and please contact a system administrator.
Hosting a personal domain would solve the signing attack: I could keep my private key off of the server entirely. But it doesn’t solve the .well-known attack vector at all, since all you have to do there is replace the public key.
February 11th, 2014 at 6:54 pm
Although I did just try to do a password reset on bugzilla.mozilla.org and it appears to have worked up through the point where I actually would enter the new password, so I could be mistaken!
February 11th, 2014 at 9:10 pm
It seems to me that all you need is a 2nd factor on the website you authenticate to (possibly in addition to the one you have for your provider).
This would be precisely as much effort for the website as implementing their own email-based auth + 2nd factor auth and at least as secure.
February 11th, 2014 at 10:53 pm
“If an attacker can replace the .well-known/browserid file on a major email provider…” they can almost certainly replace other files as well, and are free to wreak havoc on any service on that server.
“One common defense of Persona is that email providers already have access to users account via password-reset emails. This is partly true, but it ignores an essential property of these emails: when a password is reset, a user will be aware of the attack then next time they try to login.”
Except for the fact that the evidence of compromise (i.e. the emails) can be deleted/intercepted without the user being aware.
By suggesting that Persona should only be used for low value accounts, you’re suggesting that Persona is a toy login system, that should not be used at all. You give the Mozilla Status Board as an example — but that isn’t a low value target. A compromise could cause enormous financial harm to Mozilla (and perhaps even Google, Microsoft and others, via the share market), precisely because of the impersonation risk. Impersonation is always a risk.
Mozilla should certainly exercise extreme caution with Persona, and make sure that it is at least no worse than the average existing authentication systems used for banking (i.e. user/pass with lockouts on the front-end, and whatever it is they do on the back-end). But if they haven’t done that due diligence already, the project should probably be scrapped right now — if it’s unfit for high-value accounts, it’s unfit for anything.
February 12th, 2014 at 12:08 am
Ryan (not RyanC): guess what? Monica does not accept your premise. Based on her experience at Google on gmail, she finds that actual user behavior around rejected logins, whether caused by password resets or forgotten/miscommunicated passwords, combined with sharing passwords among family members, makes the situation much less clear than the “denied login, I suspect foul play” outcome asserted without evidence here. Much closer, IOW, to the compromised-IdP case.
I’ll let Monica reply if she is willing. The snotty attitude may have put her off, though. Try not to assume too much if you want a real dialog!
/be
February 12th, 2014 at 6:46 am
So you argue effectively: It’s insecure since the authenticating party might get hacked and this enables an attacker to silently sign-in as any user of that site as long as that site is compromised.
I’ll bite: Which of the currently practical alternatives would be more secure?
February 12th, 2014 at 12:16 pm
Your point is that you shouldn’t trust an IDP if you think there’s a significant possibility that their website could be compromised by attackers.
This is true, but it is not limited to Persona: All the authorization protocols I know about, specifically including the OAuth 2-based technologies such as OpenID Connect as used by Google, also rely on the use of key pairs and are open to exactly the same attack.
It seems irresponsible to me that you would focus your attack specifically on Persona when there’s nothing Persona-specific about it.
February 13th, 2014 at 2:34 am
“Except for the fact that the evidence of compromise (i.e. the emails) can be deleted/intercepted without the user being aware.”
The evidence of compromise is not the potentially deleted mail but the fact that the victim can no longer log into the site because the password has been reset.
February 13th, 2014 at 11:29 am
Also read this HN thread on this post: https://news.ycombinator.com/item?id=7219034
February 13th, 2014 at 12:28 pm
voracity, I’m not suggesting that Persona is a toy system. It’s a good system for most normal day-to-day sites and activities. I am suggesting that the Persona does not have the right security tradeoffs for protecting some high-value data such as Firefox security issues the PII of people submitting crash reports to Mozilla.
Justin, for the cases I’m talking about, where we’re willing to require manual password resets by administrators in the event of a forgotten password, I think that simple passwords may be better than Persona, but it would clearly be better to adopt a 2-factor auth system where Mozilla controlled at least one of the factors.
March 10th, 2014 at 10:30 am
Tim, you are right: I wrote this in the context of Mozilla sites adopting Persona, but it applies equally to any federated login system.