Persona - Mozilla's decentralized and secure authentication system
developer.mozilla.org
developer.mozilla.org
Has there been any writeup that explains the potential impact of Persona on privacy? Not just the impact when used as intended, but also any unintended effects?
https://www.youtube.com/watch?v=QDSh3osE4GQ
Also, see this blog post:
http://identity.mozilla.com/post/7899984443/privacy-and-brow...
Lately, there have been tons of high-profile hacks that boiled down to taking control of victim's email and resetting passwords to other accounts. What's seems to be the best response possible from web developers? Is it:
a) Demand that all your users use Gmail with enabled two-factor authentication, then smugly blame them for all security issues if they don't.
b) Stop using emails for password resets, since you don't really know how trustworthy your users' email providers are.
If you're already a password ninja and use a different and unpredictable password on every different site without forgetting them, Persona isn't an improvement in security. If you don't, as most users don't, Persona makes authentication more secure and more user-friendly at the same time.
With Persona, your weakest point would still be your email provider, which is why it would still be wise to recommend two-factor authentication for your email.
If you're already a password ninja and use a different and unpredictable password on every different site without forgetting them, AND you have enabled two-factor authentication with your email provider, Persona IS an improvement in security. This is because, with Persona, having two-factor authentication for your email would automatically mean two-factor authentication for all your websites as well.
Still, as you say, an improvement :D
As far as what to do about users? You can't fix the problem. Nothing is going to be 100% secure, and the flesh is always going to be the biggest weakness if the machine has been well designed.
If you really want conjecture on it, though, I would suggest you first ask "Is this something tied to a citizen's identity, or a online identity?", because most things that process fiat currency in any capacity will fall into the former, and should probably merit a recovery system outside of email.
I would argue, however, that anything falling into the latter and should be handled with email.
Public key crypto has many usability problems, but it solves a lot of other problems. I wish some of the big mail providers like Google would throw some money and people at it.
SMS confirmation is another mechanism, and one that is viable in most of the world, but has a different set of risks.
I think a combination of these are a good approach, but this is a really tough problem in the identity space, and if you have any suggestions on how to improve it in a way that is viable for a large user base, your feedback would be greatly appreciated!
I'd rather they made OpenID less scarry (to average Joe) instead.
When you use a computer that's not your own, Persona keeps the session time very small. Of course, when you're done using that computer, you should ideally clear cookies, just like you would if you used OpenID or Facebook on a shared computer.
This is safe on a public computer or shared device, if you logout.
Persona also has some UI around public versus personal devices.
(Maybe I'm not looking deep enough? Anyway, thanks in advance.)
More importantly, I really dislike the answer to second question from the audience. Even when the system is fully supported without fallbacks, hacking person's email account will grant the attacker ability to log into all websites as the victim?
I already am quite concerned with how much control over everyone's identities services like Gmail have. If I understand it correctly, Persona will give them more direct control over user's identities. It's only decentralized in a sense that different email providers will be able to implement it separately, and verify identities of their users.
I hope I'm missing something from the big picture here.
What's more, Persona can be used with any email provider, so users can control who they trust, or take that trust into their own hands. Because that trust relationship is more explicit, users are (as your post demonstrates) more likely to consider the implications of trusting a specific email provider, which is a good thing.
A world with better password reset policies is still a world with passwords, and leak after leak have shown that 1) it's hard to get every site to do the right thing, and 2) people use and re-use terrible passwords. Persona lets sites do the right thing by default (since there is no password to store), and it lets me as a user better control my own security.
> Even when the system is fully supported without fallbacks,
> hacking person's email account will grant the attacker
> ability to log into all websites as the victim?
The big picture is that it makes distributed identity easy for the average user to grok.
No, Gmail already has that control. Almost every website out there allows you to reset your password by sending you an email. If you control the user's email, you can change their passwords. Persona changes nothing in this regard.
2. Right now, Gmail can reset your password, but it cannot silently authorize someone else to use your account without you knowing. It seems (and correct me if I'm wrong here), that with Persona such scenarios will become possible.
2. Yes, it can. It can delete password reset notifications. If the notification contained the password in plain text, then there would be no easy way to find out whether Gmail logged in to your account on X. If the notification contained a password reset link, there is a possibility that the user would subsequently discover that their password was no longer accepted on X. But given that most users use the same password everywhere, Gmail already has a huge potential for evil, as it could just use the passwords it has already collected. Users that worry about Gmail can use an alternative email provider or their own, after all, email and Persona are both decentralised. Website developers that worry about Gmail can use other authentication methods on top of Persona, such as in-house two-factor authentication.
tldr; if Gmail is evil, both Persona and current systems can't stop it. If that worries you, use your own email server, and use other authentication methods on top of Persona on your websites.
I'm comparing hypothetical mass-adoption of Persona with hypothetical mass-adoption of alternative password reset policy. It seems like a fair comparison.
Or another way to look at it is that you put the burden of choosing a responsible identity provider on the user. If the user chooses poorly they get owned, not you.
I suppose mobile apps would ideally use some sort of Persona login service provided by the underlying OS, and until such a thing exists I guess an app could reimplement all the user-agent logic and load the user's login page in a webview. But I have no idea how at all I would go about designing an API for a website which uses Persona for logins.
The bug to watch is this one: https://github.com/mozilla/browserid/issues/2034 supporting environments without popups will clear the way for good native SDKs.
If we're going to have browser support anyway, I'd rather just use standard two-way SSL and put the work into developing better UI and private key distribution systems for it. It's even more secure and has a great user experience once you've set up the key in the browser and authorized it to the site.
BrowserID (Persona) took me minutes to implement. On a non-trivial project, it may take a couple hours. The beauty of this is the fact that it still works without built-in browser support. It's designed to be a forwards-compatible API that only becomes more usable with time.
Additionally, email is an excellent way to establish a user's identity, and the fact that it's designed around email makes it easy for a regular person to understand its authentication flow.
The problem with SSL is that it is an all-or-nothing technology. There's a chicken and egg problem: people won't make good UI for it until it's widely used, but people won't use it until it has a good UI. Persona provides an implementation of BrowserID that has a decent UI, and the user experience will only get better with time as more people use it. The chicken/egg problem is solved there, but two-way SSL right now is practically unusable for anyone who isn't very familiar with it (most people). Using an email address is very familiar, though.
I couldn't be happier with a signin solution. It even complements my legacy solution very well, you can see a demo at http://www.yourpane.com (click "Persona", never mind the email field.)
How will my mom log in to an SSL-certificate-requesting site from another computer?
That said, I'd love they succeed and we have finally something that works well and it's not under company-X's control.
With OpenID, the result of the site redirecting you to the IdP (and then the IdP redirecting you back to the site) is that the IdP can get a trail of every website you're trying to log into. That's pretty fundamental to the way OpenID is designed.
In Persona you will just click a button (because your browser knows your IDP) and then optionally sign in to your IDP. A huge difference.
OpenID usually doesn't reveal your email address.
For example, when logging in to Google via OpenID, google will only send back a unique identifier that means 'yes, the user has a google account' but no other personal information. Yahoo does the same.
(of course, it's possible to use OpenID extensions to get a user's email at their discretion)
Does persona work in the same way?
1. It prevents lock-in to Persona. (If you want to migrate away from Persona, you can just send the users an email and introduce the new authentication mechanism.)
2. Most websites will need some way to contact the user, and will ask for their email address any way.
3. Users understand the concept of email addresses as identifiers.
If you care about keeping your email address private, you can always use the features your email provider offers such as forwarding email addresses.