In principle, Persona is great. Not storing passwords is awesome, a non-FB/Google/Twitter identity option is important.
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.
Here's an example: I just failed to login to Zonino myself.
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.
Gah. We still need to switch from OpenID to OAuth for our GMail bridge; OpenID doesn't allow us to tell Google what address we're trying to authenticate. Sorry!
Normally, when you're logged into multiple Google accounts - Google Bridge in Persona lets you pick which Google account you want to use. This error you're seeing seems like some sort of bug/UX issue (?) in Persona -> Google flow where if you're already signed into multiple Google accounts, but not the extra one you're trying to use - things don't work as smoothly..
No, and that is what I would usually do since I understand how these things work. (IE does come in handy at times.) The point that I am trying to make is that normal users who don't know these tricks can run into this barrier.
Agreed. Although Persona's technical basis and privacy protections are second to none, the UX is nothing to write home about. It still feels too much like OpenID, and we know what happened to OpenID. Facebook and Twitter can get away with cross-site redirects because they're well known and people trust them. Persona doesn't have that benefit, so it can't get away with the same cumbersome UX. It needs to do better, much better. The market is unfair. Deal with it.
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.
The paradox here is that people are more familiar with the appearance of home-grown-style login systems and are more willing to follow through on those than the novel Persona flow, even though the security characteristics of Persona are stronger. It's a chicken and egg problem, and until someone really big takes the plunge and gets everyone comfortable with this style, anyone implementing it is going to be somewhat of a cost to signups.
If the bridge supports the 3-4 major email providers, it effectively becomes "log in with your email address" (it already supports Gmail), and A LOT of the friction goes away.
OpenID never really made it not just because of their bad UX design but also because they never got major players to push it to the public. Google or Facebook would much rather have you use their service as login credentials as it makes more monetary sense to do so than to hand it over to some non-profit foundation like Mozilla or OpenID. Data = money in this world and everyone wants more money.
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
There's an OpenID bridge [1] to make it easier for GMail users to sign in using Persona if they're currently logged into GMail/Yahoo! [2]. I haven't used it but the end goal of Persona is that 3rd party email providers can be their own Persona identity providers.
We definitely need something like Persona but I share your concerns WRT friction. Chicken meets egg.
Your data (especially the fact that users clearly prefer it) tells me that they're clicking it out of curiosity, to see how they can log in with their email.
Unless by "clearly prefer it" you don't mean the initial button click, but the final login?
You can see how we communicate it on our site if you're curious. Basically it's a modal dialog with four options:
* 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 did try it (and signed in) to your site. I'll admit, I knew I was going there for Persona, and "sign in via email" got me curious to click on it, even though I already knew what it was.
Just tried it on your site. It went easily enough. I entered my Gmail address in the Persona form, then it had me pick which Google account to use (strange that it wouldn't just choose the one for the Gmail address I entered), then it said I was signed in.
The gmail case is special, actually. For a few domains (gmail, yahoo, not sure which others) it will fall back to a flow that's more like OAuth. But for unknown domains it sends you an email with a link, and then requires you to create a new account (with a new password) that is persona-specific.
I agree. Though facebook tends to track users, people are so used to see the facebook login button that they feel comfortable with it. Persona, though really good, feels different and makes the me a bit uncomfortable as an end user.
We track clicks on each of the four login methods, and compare it with successful sign in events with each of them. So we know completion rates for each type, plus which types are preferred by users. Nothing fancy, just google analytics events + checking the users table.
Persona is an elegant, powerful idea that is 100% in the users interest. I dearly want to see it gain traction. Kudos for disseminating your enthusiasm.
(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.)
You may try https://github.com/wrr/wwwhisper, although unlike the apache module, wwwhisper runs as a separate service (Django) that nginx communicates with using auth_request module.
I completely agree. I was just thinking about this earlier today, there was lots of hype last year about it but it seems to have died down, and the project seems to have stalled.
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.
The team has been focused on Persona support in Firefox OS, the Firefox Accounts stuff which relies on some of the same code as Persona, and integration on Firefox desktop. They have by no means stopped working on Persona, but resources on the Identity team seem kind of limited relative to how much there is still to be done.
Hmm, right. It seems that interest has died down a bit, so maybe it'd be worth spending some man-hours keeping it alive, even if it takes away from development time. The community could maybe help with development? If not with Firefox OS/Accounts, at least with the web component.
Not elegant at all, but the best option we have supported by some powerful force (Mozilla) that can push it onto users by embedding it into their browser.
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.
I've been using Persona as my sole login mechanism on http://letscodejavascript.com for over a year. I want to love it, but I don't.
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.
Perfect solution? It works like it was custom-built for my site, is as easy and predictable to implement as Persona's `get()` API, and of course has excellent security, privacy, and operations.
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.
Persona vouches for you when you sign in. Really neat, no more password leaking.
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.
Biggest problem I have with Persona is one of it's main selling points; if you log in to one place you're logged into all the places. That may sound great, but it really isn't. It means that you can log out of a site because you don't want people sharing your machine to have access to it. You then log into a different, lower-security site. Instantly that first site is accessible again.
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!
I guess this is just a sign that I am getting crotchety, but headlines like this just anger me:
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.
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.
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.
The problem I have with that is that I haven't found decent identity providers last time I checked.
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.
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.
That's quite cool - actually that'd be exactly what I want to host myself.
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!
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?
Yes, exactly. There are currently other options if you want to be completely self-hosted (and are not a large enterprise that has multiple users and wants a behind-the-firewall option). Persowna is a more featureful/(hopefully) secure option than the default bridge.
> If you run your own identity provider, you are only trusting yourself with your secret.
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.
I got excited by SRP a few months ago and looked into it, but decided that it didn't have that many advantages compared to storing hashes properly on the server (with a strong KDF) and using TLS.
The 'storing hashes properly on the server' problem is the biggest problem with website authentication right now, as seen by the number of breaches resulting in weak-ass hash dumps.
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.
But my point is that you're still trusting your email provider with the password, and now if that get's leaked an attacker has access to (arguably/potentially) more sites than they would have before (via password resets).
That is exactly why sites shouldn't provide password reset by email. Email shouldn't be used for authentication in any case. It's really insecure solution.
Unfortunately security questions aren't much better. The best solution is to expect the user to safely and securely store a reset-key (kind of like Mozilla's Sync).
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.
Last time I looked into persona, it was essentially unusable for my usage - there's no reasonable way to use a different email address to sign up for every site. I like to know who leaked my email address when I start getting spammed.
That's one of the things I needed too, so I built this (sorry for posting it so much here): https://www.persowna.net/
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's funny that the few entities we'd be more inclined to trust are the ones that go out of their way to make sure we don't have to trust them: Firefox Sync does client-side encryption so you don't have to trust the server, Persona does authentication via an identity provider so you don't have to trust persona.org...
I didn't mean persona when I said trusting with my data. I am just saying if ever I could trust a company with my data, it would be Mozilla (shows how much I trust them).
I don't get why persona needs its own branding... Nobody knows what persona is. It should say login with Firefox. Did fb create a new brand for its login system? No it's just login with fb, same with literally every login service except freaking persona. Use your most popular brand instead of forcing all developers to evangelize a new brand. That's just not going to freaking work.
If this is the case, why not just use pseudo-crypto cross-branding and just call it: "What does the Fox say?" 350M youtube views can't be wrong, can it?
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.
This may sound paradoxical, but Persona has nothing to do with actual email. Well, except for Mozilla-provided fallback/compatibility authenticator that, indeed, uses actual email.
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.
That is true, however "login with your email" will be understood by The Average Internet User. Any discourse on login identifiers, domains, xmpp, certificates, et al will just scare them. That's a non-starter.
The problem with that is confusing users. When you have a "login with firefox" option you will get "but I don't use firefox anymore, I switched to chrome".
We use it at Mighty Spring (http://www.mightyspring.com) and it's pretty good! The documentation around backend setup is a bit confusing and doesn't cover some corner cases (like testing on dev servers) but with enough hacking you can get it to work. The front end plugin I went with (https://github.com/altryne/browserID-jQuery) needed a bit of tweaking (to both the code and docs, which was submitted to them), but other than that, relatively easy setup.
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.
The site cookie doesn't have much to do with the Persona bridge cookie. For example, for my sites, I expire users after a month, so they don't have to log in more frequently than that.
Persona never comes into it, unless they manually log out.
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.
We used Persona for http://bit.ly/blibonline - and one of the problems we faced was that we would have liked the registration process to let our users tell us the name / icon (avatar), which was missing in Persona then. Any news on the timeline for these additions to Persona? (OpenID gives those two elements from registration/usage)
I really like the idea of Persona, and it's very easy to integrate with your own site. However, it's still a bit unreliable. For example, clicking on the zonino login button just opened a mostly-blank page for me (white on the left, light grey on the right, with a pointy arrow in the middle; a bar at the bottom says "Mozilla Person...", but no way to log in.
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.
On of my biggest problems with Persona (and why I stopped using it almost exclusively) is that the popup dialog is badly designed. For instance it has email and password as two consecutive fields which confuses my password manager greatly with different accounts. Secondly does it not work at all for me on mobile devices.
The online component of Persona only matters in the interim (nothing it provides is necessary to the protocol, it is all about lowering the bar for implementers/providing support for browsers without a built in implementation). In the long term, you have to worry about whatever identity provider you are using.
Nothing depends on Persona. For example, see https://persowna.net/, which I wrote and which you can use with your own domain for authentication. You can also install your own ID provider on your site and not rely on any third party.
The UK government is about to launch an Identity assurance scheme where different providers (Post Office etc) check your drivers license then give you an account hw in is then oauth'able
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
Not necessarily. If the email provider doesn't implement the protocol, it will send you an email to verify when you log in.
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.
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".
technically - yes, it frees me from being part of (google/fb/twitter... whatever network is trendy now) and still sign in, practically,at the present moment, no - only geeks know about it
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
What happens when your email account gets compromised and the attacker uses the "forgot my password" feature on each site?
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.
Like any sensible person, all my security question answers are of the "Correct Horse Battery Staple" type.
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.
The goal of Persona is that you should be able to use Hotmail and Gmail as your trusted identity provider; the current system is just a stopgap until there's more support from providers.
you can have multiple personna accounts if you want to separate accounts assertions.
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.
My understanding of the technology is that the endgame for persona is that you don't have to trust a third party. Instead, the authentication will be provided by the browser itself (the protocol behind Persona is called Browser ID). The current implementation is just a shim until browsers provide support for it natively.
I wouln't say "just". It solves an important problem, the fact that the site you are logging in could have a javascript keylogger to read the password you are going to enter.
As JavaScript is basically a required feature on the web these days, who cares? All web browsers that anyone tests for come with JS enabled. Anyone who runs NoScript or similar knows that when sites randomly break, they need to either enable JS or accept the fact that they can't visit that site without it.
You can run your own Persona provider, meaning you don't have to trust a 3rd party.
>As JavaScript is basically a required feature on the web these days, who cares?
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.
It's generally less than 0.5% and the few techies that do it via NoScript are well aware of what to do when things break. And you'll spend far more than 0.5% of your time and budget working to make a JS-less fallback version of all your work.
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.
That's an arbitrary and useless guideline, using made up numbers. If losing 1% of your potential users costs $100k in lost sales a year, and 20% of my time costs $20k, then spending that 20% time seems like a pretty good idea.
Real teams are doing that all the time, you have to prioritize bugs, they rather fix important stuff and not care for people using IE6-8 and people using linx.
The protocol itself doesn't come with an SPOF. Only the transitional current implementation, required for bootstrapping purposes, does require the JavaScript shim hosted by Mozilla. In the future, at least Firefox itself (on desktop, Android, and Firefox OS) will come with built-in support.
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.
In Persona, the Identity Provider is not involved in each login, it just signs a temporary certificate which can be re-used by the browser, so as long as the downtime is under a few hours, the user shouldn't have much of a problem.
And if the Identity Provider's gone for a prolonged period now you've lost your identity with (almost) no means of recovery. Mostly, because, while you might believed the contrary, you didn't ever own your "own" identity in this scheme.
simply wrong. This is NOT another OpenID. Your judgment is an ignorant one. The long-term vision is even further from the current substantial departure from OpenID: to be verified by your browser instead via JS etc.
...What? That's just bizarre. I tried the Persona signup form just now on a site and I had to enter my email address, pick a Google account, and it was done. Pretty much like any other OAuth signup, so I don't see why Safari in iOS wouldn't be supported.
As someone else pointed out, Mozilla won't have to know once the protocol is more supported. Currently they're acting as a transitionary bridge, not a required element.
Also, iirc, Google doesn't have to know where you're signing in either. I'll have to double check that part.
> We think that Persona is a great attempt at improving usability, security and privacy...
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.)
That's incorrect, the identity provider is not specified by the protocol. Each user can use whatever IdP they want, with arbitrary password requirements.
It's possible to implement an identity provider, sure. But that doesn't change the fact that there are no password requirements using Mozilla's default provider. Poor default design.
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.
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.