Mozilla cutting support for Persona

[Posted March 7, 2014 by corbet]

Mozilla has announced that it is "transitioning Persona to community ownership" — or, in other words, dropping development support for this identity management project. "For a variety of reasons, Persona has received less adoption than we were hoping for by this point. However, we do still believe that Persona offers a unique and useful alternative to passwords, and we intend to support it as such. Reducing the scope of Persona and stabilizing its core APIs over the last quarter has shown us that adding more features was not the way forward." (LWN reported on Persona in March 2013).

(Log in to post comments)

Posted Mar 8, 2014 2:52 UTC (Sat) by gdt (subscriber, #6284) [Link]

Not too surprising. They were very much relying on the Mozilla branding to carry them through, rather ignoring the lessons of the federated authentication projects before them. You can still see some of this in their lessons learned. Native plugins are essential -- if you can implement it with web pages then it will be scammed. There's a simplicity/complexity tradeoff: aiming for simplicity alone runs out of steam pretty promptly after the demo when real people try to do real things; aiming for enough complexity to cover all use cases just blows people's minds so badly that it never gets deployed in the first place. I'm still not sure that they realise that web-only authentication is a road to long-term failure.

Federated authentication is a difficult endeavour. The universities of the world have put considerable resources into it across twenty years. We still haven't cracked it (although we can declare success for the case of Eduroam on WLAN). This isn't because of technology issues, but getting the design, politics and marketing right. Federated authentication projects are highly vulnerable to minor errors at the start dooming the project at the end. I'd go so far as to say that they are uniquely hard.

Mozilla cutting support for Persona

Posted Mar 8, 2014 8:08 UTC (Sat) by ncm (subscriber, #165) [Link]

I just learned more than I had ever known about federated authentication.

Mozilla cutting support for Persona

Posted Mar 8, 2014 11:36 UTC (Sat) by zzxtty (guest, #45175) [Link]

I went to an interesting presentation on Moonshot a couple of months ago, it's an evolution of Eduroam, federated access to any type of service.

https://community.ja.net/groups/moonshot

I was skeptical to begin with, however it was clear from the presentation that they have given it a lot of thought, it will be interesting to see where it goes.

Mozilla cutting support for Persona

Posted Mar 8, 2014 14:57 UTC (Sat) by ewan (subscriber, #5533) [Link]

I suspect that Moonshot will wind up falling on the 'too complex' side of these things. In contrast with Eduroam where all the clever stuff is hidden behind the standard interface of WPA2, and Shibboleth which hides it all behind web pages, Moonshot needs specific support on the client system.

There are existing projects that have found some degree of domain-specific success (e.g. IGTF in grid computing), but it's been hard to get traction outside the narrow fields that originated them, even for very similar applications, because people don't want to have to deal with even a small degree of extra complexity.

Moonshot is well named - it's going to be great if they can pull it off, but it's at least as likely to crash and burn.

Mozilla cutting support for Persona

Posted Mar 8, 2014 21:29 UTC (Sat) by gdt (subscriber, #6284) [Link]

I suspect that Moonshot will wind up falling on the 'too complex' side of these things

It appears to be developing that way. I suspect that using RADIUS as a transport may made writing code more difficult than necessary. It may have been better to use a simplified EAP directly over SSL.

Moonshot needs specific support on the client system

That is pretty much the result of experience with Shibboleth, which asked for authentication details via a web page. Which of course is easy for an attacker to fake. However, I fear that Moonshot's complex protocol has made writing the many required plugins too hard.

On the plus side, steering authentication to its backend using DNS SRV records and then doing an end-to-end check that the backend is valid by following a certificate chain is so obviously the "just right" solution. We built a hierarchy of proxy servers for Eduroam, and we never want to do that again. Identifying people as principal@realm is obviously right. Shib uses a dropdown to select the realm and that's too hard a user interface for non-web authentication.

We know we need attributes. But we also know that too simple or too complex set of attributes will kill a system. We also know that it has to be complex enough to gateway into the eduPerson LDAP schema, POSIX users and groups, and MS AD. But that supporting every possible convolution of those external systems is death (OAuth2.0).

Still open is the amount of trust needed and desired. Facebook is at one extreme (the resource is told a ridiculous amount about people authorised against it), Shib at the other (the resource knows the user is authorised, but that's all). There's a lot to be said for being at the less trust end: it's simpler in the future to pass more information than to pass less; and Facebook pretty much owns the other end of the spectrum.

As I wrote initially, this stuff is hard.

Mozilla cutting support for Persona

Posted Mar 8, 2014 21:59 UTC (Sat) by raven667 (subscriber, #5198) [Link]

> experience with Shibboleth, which asked for authentication details via a web page. Which of course is easy for an attacker to fake

I have a small amount of experience with Shib at a single site, but I'm not sure what scenario you are referring to here? The credentials are only handled by the central service for that site, for example https://login.college.edu, which is at least as good as any other SSL page when it comes to attacker fakability. Is there some problem with asking for credentials via a web page or something different about how it works in a multi-site federated way that you are referring to?

Mozilla cutting support for Persona

Posted Mar 10, 2014 5:06 UTC (Mon) by gdt (subscriber, #6284) [Link]

Is there some problem with asking for credentials via a web page...

As it turns out there's a lot wrong with it. Mainly, it's too easy to fake using another webpage. The user interface is wrong too: you're training your thousands of users to entire their userids and passwords into a webpage which magically appears. But there are other issues with not using the platform's authentication handling: too hard to integrate authentication devices; difficult to handle accessibility; bypassing any hardening against keyloggers; too hard to use from non-web environments which means you need a second federated authentication system for those; and sometimes a webpage is simply a poor fit to the device (eg, phones, 802.1x network authentication).

A simple way to write lots of native plugins is the current feeling of where we need to going. But this isn't a science, no one really knows what a really successful system looks like, we just know the shortcomings with the systems we have built. However it's well worth trawling that experience for lessons when designing new federated authentication mechanisms.

Mozilla cutting support for Persona

Posted Mar 10, 2014 6:20 UTC (Mon) by ibukanov (subscriber, #3942) [Link]

> Mainly, it's too easy to fake using another webpage.

This is very spot on. Ideally browsers should support a special very hard to spoof GUI for authentication performing SRP [1] or J-Pake [2] - like protocols that never leaks passwords and authenticate both the user for the server and the server fort the user.

But I suspect easy-to-fake authentication will die only together with the idea of using passwords that one feeds to the browser...

[1] http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol
[2] http://en.wikipedia.org/wiki/Password_Authenticated_Key_E...

Mozilla cutting support for Persona

Posted Mar 10, 2014 14:54 UTC (Mon) by raven667 (subscriber, #5198) [Link]

I see your point now, thanks for the explanation

> it's too easy to fake using another webpage

I would say that this is a risk you are going to have to get up close to and become comfortable with if using any web application because I only see three different ways that authentication is handled today: password entered into app and stored in app database, password entered into app and passed on to ldap or radius, password entered into shib or openid or whatever that creates a token which can be validated. Of these choices I think shib is the least risky as it takes much of the web applications security out of scope, at least as far as password handling is concerned.

> using the platform's authentication handling

You can cover much of the same ground that shib covers with kerberos, they are very roughly similar technologies, but the world doesn't seem to be moving in that direction. Even in environments where kerberos support is a given (Active Directory) many apps will integrate with LDAP auth rather than kerberos and those same apps wont work with shib either.

> bypassing any hardening against keyloggers

Maybe i'm wrong but I don't think even MS has kept their keylogger hardening, every OS these days puts security dialogs right in the main UI and doesn't require a SAK like Windows used to, any app which can put up dialogs styled like the system password ones can probably con credentials out of most users.

> too hard to use from non-web environments which means you need a second federated authentication system

Yep. Right now you can have one backend user/credential store but you will have to make it available via many protocols such as shibboleth, kerberos, radius, LDAP to cover the authentication needs of most of your applications and services.

> no one really knows what a really successful system looks like

Yeah, the best we have is what we have right now. Maybe some day a particular technology will gain critical mass such that it becomes well supported with OS-native credential handling that takes some of the existing risks out of the loop, but I'm not holding my breath, I'll take whatever pieces and parts to at least make part of my life easier that exist today 8-)

Eduroam

Posted Mar 8, 2014 13:39 UTC (Sat) by tialaramex (subscriber, #21167) [Link]

Eduroam benefits from being the right "shape" for federation. Individual Eduroam member institutions are not so tiny as to have no capability to obey rules themselves or enforce policies on their users, and yet none is so large as to dominate Eduroam and dictate everything.

There is a powerful network effect. The cost to each institution is some training, maybe slightly more expensive hardware purchases, and work needed for correct configuration. This is small and proportional to the institution's size. In contrast the benefit is proportional to the size of the entire network (at least to the extent that the institution's staff or students travel elsewhere). As a result every institution can look at Eduroam and see a net upside from membership.

Finally, in Europe where Eduroam began the institutions in almost all cases already had a relationship with their NREN (e.g. Janet). So instead of creating a new entity to handle the federation it was just an extension to the existing non-profit that ran other useful services for the institutions joining the federation. That makes a lot of things simpler, not least it ensured there was no competing alternative. One can imagine that an Eduroam-like system spawned in the US would immediately have had six competitors, each championed by a different for-profit further education provider hoping to develop a new income source. Such fragmentation would be fatal.

Mozilla cutting support for Persona

Posted Mar 8, 2014 14:48 UTC (Sat) by KaiRo (subscriber, #1987) [Link]

I wonder when people will learn that "transferring to community ownership" doesn't mean "cutting support"?

Diaspora* has been transferred to community ownership and is very much alive and doing decently (but federated social networking is just as hard as federated identity), and Thunderbird has been transferred to community ownership within Mozilla and is alive, doing well, and getting regular releases done. Heck, the original Mozilla application suite was transferred to community ownership back in March of 2005, and it's still running decently (under the "SeaMonkey" banner) and shipping releases pretty much in sync with the Mozilla platform and Firefox!

Just as with Thunderbird, Mozilla isn't even cutting off any infrastructure resources here - as the announcement says, "Mozilla staff will continue to resolve critical bugs, service disruptions, and security issues. Moreover, Mozilla’s new network operations center will handle tier 1 incident response for Persona. The center’s robust, human-backed, 24/7 monitoring will further increase Persona’s reliability and improve incident response times." Also, Mozilla is continuing to use Persona as the login system of choice in many of it primary web assets, so it's even critical for Mozilla itself to have the service running smoothly.

The only thing that happened is that full-time paid Mozilla employees are not spending their work time on developing Persona any more. I guess that a few of them will continue to help in their free time. Some parts of Persona are being used in Firefox Accounts, and Mozilla employees are continuing to send their work time on developing those parts, as Firefox Accounts are becoming part of Firefox and Firefox OS.

As the announcement also says: "There are no plans to decommission Persona. If it fits your needs, please use it. We will support you."

And if you want to help developing it further, now is the best time to jump in!

Mozilla cutting support for Persona

Posted Mar 8, 2014 22:03 UTC (Sat) by liam (subscriber, #84133) [Link]

I've recently been receiving messages from my android nightly saying that I should move from sync to persona. I use my persona account to log into the Mozilla infrastructure and now they're going to stop developing it? I know that doesn't mean it will stop working but it leads me to think that they are going to create yet another authentication method that I'll need to sign up with.
Not happy at all...

Mozilla cutting support for Persona

Posted Mar 11, 2014 19:07 UTC (Tue) by KaiRo (subscriber, #1987) [Link]

Persona will continue to be used as the primary login for a lot of Mozilla infrastructure and will be supported for that.
Sync is not moved to Persona but Firefox Accounts, which uses some of the Persona code but is different in several aspects, including the fact that it is not federated.

Mozilla cutting support for Persona

Posted Mar 9, 2014 9:38 UTC (Sun) by job (guest, #670) [Link]

"Less adoption"? What's with the impatience? I would expect that it takes at least five years to even make a dent in the indentity market.

This project is three years old. So this is like if Linus had said in 1994 "Linux hasn't had the adoption I hoped for" and dropped the project.

The identity market is conservative for a good reason. You can't even support the idea during the incubating period, but somehow expect us to trust you for managing our identities for the forseeable future? (Yes, I know Persona is a distributed system, but the project itself is under Mozilla's control.)

Mozilla cutting support for Persona

Posted Mar 15, 2014 3:31 UTC (Sat) by k8to (subscriber, #15413) [Link]

Thankfully Linus didn't have any product managers.

Mozilla cutting support for Persona

Posted Mar 9, 2014 22:09 UTC (Sun) by robla (subscriber, #424) [Link]

Here's informative thread about the state of Persona on Mozilla's dev-identity mailing list. In short, it looks like one of the dependencies is the work of the IETF JOSE working group, which, still being in draft, could be subject to further change. They also seem to have some disagreement about how the UI for browser-native Persona should work.

While these developments may not bode well for Persona as currently implemented, it seems smart for them to build out a login service that works for Mozilla's internal needs while the dust settles on some of the underlying infrastructure. Given the Persona devs are going to be working on Firefox Accounts, I'd have a hard time believing they won't figure out how/where to integrate it if it makes sense, and if it doesn't make sense...well, it must really not be meant to be.

Mozilla cutting support for Persona

Posted Mar 12, 2014 2:33 UTC (Wed) by jamesh (guest, #1159) [Link]

Persona never seemed to deliver on many of its promises: while it had some nice theoretical features, the recommended implementation plan often nullified those benefits.

For instance, one of the complaints about OpenID is that the identity provider knows about every site a user logs into, which has privacy implications. Persona is supposed to get around this through a system where the identity provider provides a certificate to the user's browser letting them prove who they are to relying parties.

But rather than providing a library that RPs could use to download the public key of the user's IdP and verify the signatures, most RPs seem to be using Mozilla's remote verification API (https://developer.mozilla.org/en-US/Persona/Remote_Verifi...). Essentially, they send the signed JSON blob from the browser off to a Mozilla server and get a response indicating whether it is valid and the identity of the user. So you've now got a single service that can see the results of the majority of Persona logins over the entire Internet.

Another promise was that you'd have a Javascript API implemented by the browser that could then provide a UI to the user that could not be forged. However, no browser implements this API, so a stand-in is provided implemented in JavaScript that uses the login.persona.org site to implement the UI. Both RPs and IdPs are expected to include this offsite JS into their login pages. If they follow this advice and login.persona.org is compromised, then an attacker could run arbitrary JS code in their origin.

Further more, if the attacker gained control both the JS blob and the remote verification API, they could likely log in as any user on any site using Persona (even for users who have set up their own Persona IdP). This would seem to make it no better than e.g. Facebook Connect login.

Mozilla cutting support for Persona

Posted Mar 20, 2014 10:00 UTC (Thu) by ssokolow (guest, #94568) [Link]

Yeah. Things like remote verification and having to use a remotely-hosted shim because the wire protocol is still being iterated on are why I haven't used it on any of my sites.

...well, that and I wouldn't want to be a hypocrite about expecting other people to deal with a UI that doesn't like "one e-mail alias per account" when I wouldn't.