Why we love Mozilla Persona
blog.zonino.co.uk
blog.zonino.co.uk
I would encourage you, though, to look carefully at your login completion metrics. I implemented Persona on my site (http://www.sixquestions.co) to have a pure email option and although users clearly prefer it, about 35% complete the Persona login flow successfully. That's 10 points lower than our next-worst performer (Twitter), and half the rate of our best performer (Facebook). For all the concerns people have with authorizing Facebook/Twitter access, that is (in my view) offset by the alien-ness of Persona's login flow. We've heard from lots of users that logging in with Persona is unusual and they thought they were doing something wrong because they'd never seen anything like that.
So, as much as I believe in Persona, I'm about to deploy a change that removes it entirely. It adds a lot of surface area to our testing and future development, but if it means we lose fewer users in their signup flow, it will be worth it.
I enter in the Gmail address that I use for registrations and other junk. I get the message: "Accounts don't match. You are currently signed into Google as [my normal Gmail address]. ... Force Google logout?" Forget that. I'm not interested in logging out of Gmail. Logging out of #1, into #2, out of #2 and back into #1 is more work that simple registration. I expect that I'm not the only person with this problem. I hope a solution can be found, because it would be really helpful.
All it takes is a personal Gmail account plus working for a company that uses Google Apps.
If you're in the business of implementing an alternative login system, you should also seriously think about what kind of UX you're competing against. Your ultimate competitor isn't Facebook or Twitter. It's the good old email-and-password login system that everyone is used to. You enter your email address, select a password, and you're in, without ever leaving the signup page! It's even easier if you use a password manager like LastPass. That's what you're competing against, and if your UX has any more steps or redirects than that, you're probably doomed.
Google's FriendConnect was built on it.
That's a fair bit of "push".
1) users don't already have a personna account setup. They're used to hit their "login with FB/Google" account instead. They don't know that persona is better privacy-wise. So for many, it's just friction.
2) persona login sometimes appears slightly slower
We definitely need something like Persona but I share your concerns WRT friction. Chicken meets egg.
[1] http://identity.mozilla.com/post/56526022621/what-is-an-iden...
[2] http://identity.mozilla.com/post/57712756801/persona-makes-s...
Unless by "clearly prefer it" you don't mean the initial button click, but the final login?
* Facebook * Google * Twitter * Email
We don't use the persona messaging, and I think people's expectation when they click the 'email' button is that it's going to just be a normal email flow. We don't call it Persona or Browser ID or use any of their assets or messaging, because we didn't think anyone would click on it if we did.
But yes, we see a small preference for a button labeled 'email' versus facebook, and a medium preference for either over twitter.
I really want to see it pick up steam and succeed, and I think the number one priority now is to implement plugins for major browsers. I hope the team picks up development again.
To be fair, it's also pretty hard to help out while the team is focused on doing other stuff.
https://github.com/mozilla/mod_authnz_persona
(I know Apache may not be that popular with the HN crowd anymore, but I don't currently have the time to dive into nginx and do the same for it. Nevertheless, if anyone wants to do that, I'd be happy to answer questions and provide pointers into the Apache code.)
I still love it. Thanks for the module.
Personally, I view Persona as just an awkward kludge that, while improves some important things, also does certain harm by pushing us one step away from making third parties mere notaries of one's identity, not its very providers.
Because it's me who's the source of my identity, nor my email provider nor domain registrar.
The goals behind Persona are excellent: strong privacy protection and relieving website operators of cumbersome and error-prone authentication management. I love the idea. It's why I implemented Persona on my site.
The execution of Persona has been a bit wobbly. Logins are critical infrastructure and it doesn't feel like Mozilla is approaching Persona from that perspective. The team has been fantastic (thanks, callahad) but when things go wrong, it can take a long time for them to get resolved. Meanwhile, I'm left scrambling for a workaround.
An example: when the Yahoo bridge was implemented, it broke Persona for everyone who used a Yahoo alias [1]. A nasty break that returned a non-helpful error message. Something that serious merits an immediate rollback, in my opinion--but instead, it was left in place for several weeks until a interim solution was rolled out. The interim solution has some fairly serious UX problems, but the full solution has been open for 10 months now [2].
I want to love Persona, and I can't really afford the time required to do my own authentication, but it scares me that I'm so dependent on it.
[1] https://github.com/mozilla/persona-yahoo-bridge/issues/178
[2] https://github.com/mozilla/persona-yahoo-bridge/issues/201
> ...I can't really afford the time required to do my own
> authentication...
I would have been willing to pay for such a thing had it existed when I started. It would have needed to be proven, though, because I worry about longevity. The exact price isn't so important, within reason; say, less than $100/mo. At the higher end of that range, I'd expect it to have some serious word-of-mouth gushing.
I believe it deserves it, but more collaborators should chip in, or more websites should use it in order to make it elegible for more resources.
The important thing here is that as Persona protocol (BrowserID)'s creator, Mozilla really really wants someone else (potentially YOU the user) to run the Identity Bridge. Currently Mozilla does this for non-Gmail and non-Yahoo users too boost adoption. So when you sign up you are asked to give a new password on sign up. If you are paranoid, you should of course give a new password instead the one you use for your email (which I assume may be reused for multiple accounts...)
But being able to authenticate yourself on your own is what makes Persona useful.
edit: at realworld crypto, this was given as a talk. This is Google's possible direction.
I wrote a whole thing on Persona a while back ( http://lepidllama.net/blog/trying-out-mozilla-persona-browse... ) but that ended up being the killer for me. It might be fine for activities like posting comments on a blog, but any site which stores or presents some aspect of who am I to the world needs to be a bit more secure than that!
Why we love/like X, And why you should, too
My immediate reaction is always something along the lines of, don't presume to tell me why I should like anything. Tell me why you like it, and be done with it.
https://github.com/sergiotapia/ASP.Net-MVC3-Persona-Demo
Authentication is simple to implement and you don't worry about user password protection.
I'm surprised interest has died down for the project given how easy it is to use. Maybe Mozilla should market it more?
But it also proof that being awesome not only is not good enough to be successful, but simply doesn't matter. The user is not interested in a solution that is awesome, but one that doesn't scare him. And a big ugly third-party popup is as scary as stuff on the web gets these days.
Remember Ogg Vorbis?
Persona might find its own niche, even if it never completely displaces Facebook user authentication on the web.
I love Persona and I love Ogg Vorbis, but both fail(ed) at understanding what _normal_ people look for in authentication/audio compression formats.
We need to move towards protocols like SRP[0] in general so that no matter where I'm logging in, noöne has my password.
[0]: http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol
EDIT: As ubernostrum points out, Persona is solving a different problem than SRP does. However, one of the reasons different identities (username/password combinations) are encouraged currently is because providers can't be trusted with the secret of your password.
If you run your own identity provider, you are only trusting yourself with your secret.
Also, nothing about Persona requires password-based authentication -- you can use any mechanism you like to authenticate to your identity provider.
Good point.
> Also, nothing about Persona requires password-based authentication -- you can use any mechanism you like to authenticate to your identity provider.
Good point. However, since noöne uses SRP or anything similar, de facto you're still sharing a secret (unless you're running your own provider).
Without some decent/proven implementations I'm hesitant to use it. I don't quite like using Mozilla's service (mostly not because of trust, it just feels half-assed not to go the extra mile and is considered an intermediate workaround/solution even by Mozilla, as far as I know). Without decent options to self host I guess I could implement it myself - but that's a big step.
So .. although I'm a fan of the concept, I'm still not using Persona anywhere.
https://bitbucket.org/djc/persona-totp
It's less than 150 LOC of Python code (plus some HTML templates and a few basic tests).
I do like the site and I think it's a clever thing to build a service around it. But .. all of your options (well, all affordable ones, all that I even looked at for myself plus family) are hosted, right? I could use my own domain, but you'd be the endpoint?
Don't take that the wrong way, but you're not more trustworthy than the Mozilla Foundation.. :)
Please correct me if I missed something, but it seems as if you interpreted my self-hosted as 'can use your own domain name', no?
https://github.com/wulczer/persona-idp
It uses my Mail Transfer Agent to identify, so I can just use me email password to log in to Persona-enabled sites, but you can easily swap it out for a different credentials checker.
Not a fan of go (cough The stripe CTF made it again clear that go get isn't exactly what I want, ever), and don't want to build stuff on my box, but I'll certainly check it out. Thanks for chiming in!
And the service I run the identity provider on. And the janitors they hire. And the legal jurisdiction it resides in. And the people (voters, oligarchs or dictators) who control that legal jurisdiction.
A secure log-in system does not require any secret which leaves my immediate personal control. This is not rocket science, and is not difficult.
My laptop browser should have an internal secret key; I should be able to get an account on a site with a site-specific key; I should be able to authorise a site-specific key on my desktop to access the same site. Heck, I should be able to connect from a public computer temporarily, and authorise the same usage with my phone. No passwords or long-term shared secrets required. If my laptop, phone or desktop is stolen I should be able to, with some inconvenience, kill the access for that device and only that device.
None of this is rocket science. It's all very possible, and the UI could (I think) be quite elegant. In part, I blame X.509 and the CA mafia for making it so tough: it was in their interest to have a rigid global hierarchy rather than a free-flowing ecosystem; it was in their interest to make certificate minting expensive rather than free (never mind that the root of any certificate hierarchy could still cost...); it was in their interest to tie identity and authorisation, which simply doesn't make sense.
One of these days I really do need to brush off SPKI, clean it up and try to push it as a solution. The guys who designed it thought long and hard about identity and authorisation, and they came up with some damned smart solutions.
You should avoid reusing your passwords across sites. BTW Persona helps you with that.
However, to the average, non-techie user this is
* Bad UX * They won't store it securely * They'll lose it
Another option is using public keys with some form of transition mechanism.
With SRP the derivation of strong keys using a KDF is done by the client. Not only is this more scalable, it means users don't have to trust web developers, who are almost never cryptographers, to get the 'storing hashes properly' bit right. Not having to trust is great. Not having to trust websites with our chosen passwords also means most of the risk of reusing passwords across services just goes away. In short it's epic win for users, but it's extremely difficult to get people to see that the real problem is a bad trust model.
Another reason to like it is it's safe to use over vanilla unencrypted, unauthenticated connections, which could be important because certificate authority integrity is, imho, the second biggest trust issue on the web right now.
Persona and OpenID etc are flawed because they copy that very same CA trust model.
Edit: looks like they may have have fixed it: http://support.mozilla.org/en-US/kb/how-do-i-manage-my-perso...
Though I'm not sure if it remains usable with hundreds of email addresses.
You can add your domain as a catch-all, so you can authenticate with anything@your-domain.com and it will use a single account to authenticate. Services will still see your custom email address, but you only need one password.
It just a protocol that - oversimplifying things - allows a certain server (identified by domain name) to issue you a certificate that says that you have a name associated with that server.
It's usually an email, but can be anything that could be represented as (name, domain) pair by concatenating those with "@" character. For example, XMPP ID, forum nickname or system account.
We use "login with your email".
Popularity is one thing, but if a user is using Persona login on Chrome or some non-FF supporting browser, and it says "Firefox login", they're probably going to be confused, and possibly close the tab. As a site owner who's implementing Persona, that's the exact opposite of seamless.
Our site is uniquely targeted at developers, so I felt that using Persona as a login option was only natural.
The one small complaint I would have is that it would be great if (after initial setup) the login process was a bit faster. It should be quicker than the old-school username and password IMHO, but with the animations and latency on authentication it all seems to feel a bit sluggish. Especially as the cookie for it expires frequently - which is a bit shit for users of a forum where you're normally signed in until you decide otherwise.
This is still in my minor complaint box because I suspect there's tweaks I could do which I haven't had time to explore yet.
Persona never comes into it, unless they manually log out.
https://developer.mozilla.org/en-US/Persona?redirectlocale=e...
Edit: I've checked out the login process in the linked site, and it works well, but the popup window U/I seems like it's ripe for phishing attempts. It would be very easy to replicate the look of that window and fool people into thinking they're using Persona when they're not.
If I do "F10 -> View -> Page Style -> No Style" I see various boxes, but it's not obvious how to proceed. I entered my email into the top-most box and tried clicking the "next", "sign in" and "OK" buttons, but none of them responded (there's also "continue", but that's greyed out). I think I had the same problem when I tried it last year.
Probably just some browser plugin issue, but would be nice if it were easier to debug... Works in Chromium though.
1. open two copies of the page
2. click the "Sign In" button on both
3. a working Persona sign in appears in the first tab
You don't own a domain, you only temporarily lease it from a registrar. Just like with the email account with an email provider.
Some cloud evangelists try really hard to change that, though.
in short Facebook logins but with actual real names that like governments can trust
just saying that this might be the start of what usually happens to private companies colonising what turns out to be a public good
Thanks to Identity Bridging on the Mozilla Identity Provider, Persona can also use the APIs of supported providers to verify your identity: it can verify a Gmail address by connecting with your Google Account, and has something similar for Yahoo! Mail as well.
I'll stick to my many accounts / many passwords approach, I think.
Any account will be compromised - it's only a matter of time. When that happens, it's best (as recent articles in Wired, Ars Technica and others demonstrate) to have a broad account "ecosystem".
What about Facebook/Google/Twitter Sign In buttons - do you think Persona is an improvement over those?
Edit/update: if compromised, you loose all linked accounts, however, with google/fb/.... it is the same, but this is less leaky to 3rd party, if this comes as default login, then we would have only a dozen of logins (persona/email, + important accounts, e.g. banking something similar... ), not ~100 of them, thus resetting 100 passwords is just 1 action
If you say you use multiple email accounts, then you can also use multiple Persona accounts. In fact, support for multiple accounts is part of the plan.
I don't see how introducing a single untrusted third party, many accounts or otherwise, is better than using a couple of trusted third parties such as gmail and hotmail.
i actually don't think this argument holds water.
it's the same with any auth system. you can use 2FA, etc. in the end if someone compromise your laptop you're screwed, they get all the passwords/assertions anyway.
They can't make assertions from the server side.
I think I'll stick with my 20 doors with 20 locks.
Persona is very convenient for users, but it would be more secure to not trust a 3rd party.
You can run your own Persona provider, meaning you don't have to trust a 3rd party.
People who don't live in a fantasy bubble world where that is true? "Hey, just throw away 1% of your potential user base for no reason" isn't a very compelling sales pitch.
The number of people who have JavaScript disabled and don't know how and when to re-enable it is so small as to be irrelevant.
The caveat to this rule is, of course, if you have a site that is very heavily trafficked.
It's like supporting IE6 at this point. It's a tradeoff. And for the vast majority of us, it's a near-complete waste of resources to cater to them.
Give me separate logins and KeePass any day.
And, quite importantly, running your own identity provider (which is another SPOF in many systems) is pretty straightforward and well-defined in the Persona ecosystem.
That's exactly what SPOF is.
Also, iirc, Google doesn't have to know where you're signing in either. I'll have to double check that part.
We use Persona and love it. However, I wouldn't trust Persona for securing sensitive information. There seems to be no password requirements (at least when I checked months ago.)
I built my own IdP that has 2-factor auth, for example: https://www.persowna.net/
Btw, your service sounds very nice for those interested in securing a domain, but I was a little surprised by the pricing. Nearly as much as a Google Apps license itself.