Mozilla Persona: Future of Authentication?

While doing research for a new analysis of modern authentication last week, I discovered that Mozilla had released the beta distribution of Persona, a new authentication system Mozilla describes as "an easy way to sign in to a website." I become so enamored with Persona that I figured that it deserved a quick posting rather than get buried into an analytical perspective that will not look too favorably on modern authentication mechanisms. Consider yourself teased.

This posting introduces Persona as an authentication mechanism, discusses the advantages that organizations and individuals could gain from using Persona, and some of the new vulnerabilities that they should consider before using Persona.
I like the Persona concept because it simplifies security, in this case the username and password authentication process. Complexity is the bane of any security solution; the easier to use, then the more effective it will be. A critical problem with using this standard authentication process is that every interaction a user may have with a device, application, or web site may require a new username and password pair, managed by the recipient system. Rules for username structure and password complexity vary across the spectrum, forcing the user to "remember" an ever-growing list of combinations. Because users can't possibly remember the rules for all of their interaction, they're forced to either maintain a list of their accounts or depend on a third-party password management tool for account management. Persona falls into the latter category.

Most password management tools (KeePass is a good example) require the user to store a username and password pair for each application in a central repository protected by a master password. Once the user unlocks the repository, then it is available to use for any application or web site login with various levels of automation depending on the tool. Users only really need to remember one password and use the password management tool to remember the rest.

For Persona, the master repository resides online. Users may begin by registering at the Persona web site with a valid email address and password. Mozilla sends a verification message to a user email address and the user follows the instructions to register with the service. Yes, it's yet another account to manage, but stick with me for a bit.

Persona improves on most password management tools by not requiring the user to store a variety of credentials in a central repository to access web applications. Using a method similar to social networking sites such as Facebook, Google+, and LinkedIn, web site owners may enable Persona logins by putting some basic code into web servers that will enable web sites to support logins from Persona users. That code will enable the the web server to accept Mozilla as a trusted proxy for user credentials and to depend on Mozilla to verify the username and password combination for authentication.

Unlike the social network logins, Mozilla promises not to track user login activities. This is a great next step in the personal privacy battle given that Mozilla has no commercial interest in collecting user data and is widely considered trustworthy. In fact, Mozilla only requires an email address and password to set up a Persona profile. Adhering to the "Need to Know" security principle, Mozilla doesn't require any more information than it needs to authenticate the user. The user is in control and maintains individual responsibility to provide additional personal information required by any individual site rather than risk data leakage between the site owner and the associated social network owner. Persona also allows one user to use multiple email addresses and attach them to a single profile and password, enabling users to easily segment different online "personas," such as personal, business, school, etc. As a security professional, I have to recommend against this particular practice since it attaches all of a user's online interactions to a single password, but most folks will likely ignore that advice and instead focus on the ease-of-use aspects.

In its initial form, the Persona communication follows this pattern:

1. When users access a Persona-enabled web site, they click on the Persona login button.
2. The web server then checks with the user's browser to verify that the user has a valid credential with Persona from having previously logged in to Persona. If not, then it provides the user a dialogue box for the user to log in to Persona. Persona will respond to the users browser with an "assertion." The key point here is that the web server is completely left out of the authentication loop.
3. The browser then returns the "assertion" to the web server.
4. The web server sends the assertion to a verification server (typically a Mozilla service) to make sure that the assertion represents a valid Persona user.
5. Upon receiving assertion verification, the web server may then proceed to allow the user access to the web site as it normally would.

Through the Persona authentication process, Mozilla empowers the user to accept greater control over web site username and password pairs. But, the greater control comes at an architectural expense related to availability. Since both the user and the web site owner depend on the Persona service to grant the user access to web site resources, Persona represents a "Single Point of Failure." Should the Persona services be unavailable for any reason, then the user would likely be unable to log in to a Persona-enabled web site until the Persona services return to normal function. Also, if Mozilla ceases to support the Persona services in the future, then the web site owners and Persona users would have to find a way to release their dependence on Persona.

But, it's how Mozilla addresses this "Single Point of Failure" vulnerability that impresses me most. Mozilla developed the Persona architecture to allow decentralized command and control, essentially allowing anyone to accept responsibility over two critical components of the architecture: assertion verification and authentication. I believe that this decentralized architecture is Persona's greatest asset to organizations and individuals.

In reference to assertion verification, Mozilla provides its Persona verification service address but grants the web site owner the ability to enter any Internet address in its Persona code to verify Persona assertions. This means that an organization could conceivably stand up its own Persona verification service and make its address available as an alternative to Mozilla's address. I could see how businesses or even individuals could use this capability to stand up independent verification services to support specific business needs, even making the service available to business partners for external collaboration or networking purposes.

Similarly, Mozilla provides its own "Identity Provider" (IdP) for the core authentication process, allowing users to apply any email address for Persona authentication. But, the Persona architecture allows any organization to become an IdP for its domain, empowering it to control all authentication for email addresses it owns. When an organization follows the steps to become a Persona IdP for an email domain that it owns (e.g. example.com), then users with email addresses in that domain (e.g. user@example.com) would have their browsers directed to the domain owner for authentication in step 2 above rather than to Mozilla. Even if the user registers that email address with Persona before the organization becomes a Persona IdP, once the domain owner becomes an IdP, it will immediately take control over all Persona authentication associated with the domain.

Because Mozilla designed the Persona architecture to empower decentralization of the two most critical functions for Internet-based authentication, it enables organizations and individuals to use Persona as more of an open authentication protocol than a service.

For organizations, Persona represents a potentially very powerful tool for controlling how users leverage their domain email accounts to register for and use online services. Whereas those users could easily choose or be led to provide an email and password combination to untrusted third parties that matches what is needed to access proprietary internal information and resources, Persona-enabled sites would empower the organization to retain control over the password element should it become an IdP for its email domain. Organizations could also leverage Persona as a free and open method to enable single sign-on to internal web sites and applications. I could also foresee value in several organizations in a specific market or functional area leveraging Persona to easily authenticate to collaborative resources in a more controlled extranet environment.

Individual users could also gain great value in applying Persona to more easily maintain anonymity and gain new control over their online identities and profiles. The ease with which Mozilla empowers users to become an IdP, users could potentially stand up individual email domains and then direct all Persona-enabled sites to a user-controlled authentication service. Users who take advantage of this capability would then be assured that external organizations would have no access to their password information. This would prevent those users from having authentication information disclosed inadvertently or due to a malicious attack and would help defend against social engineering attacks such as the recent attack suffered by Mat Honan when his entire digital life had been erased by a hacker seeking access to his Twitter handle.

To be fair, I don't believe that everything about Persona is roses. In addition to being dependent on the same unstable and risky foundation as all modern authentication solutions (another teaser), Persona may introduce new man-in-the-middle vulnerabilities that organizations and individuals should carefully consider. For example, while Mozilla requires organizations to receive a digital certificate from a trusted third-party certificate authority to become an IdP, there is precedent for a crafty social engineer to convince one of those third parties of domain ownership and hijack the Persona authentication process for long enough to infiltrate corporate networks. In scenarios where the true domain owner does not register to be an IdP, a hacker or malicious insider may be able to control Persona authentication for an organization without the domain owner's knowledge.

Owners of Persona-enabled web sites would also face the reality that they have very limited ability to trust the identities of their users, only the assertion that some IP provides them that the user has the information necessary to activate a valid site session. In reality, non-Persona authentication suffers from the same constraints, but when a web site is essentially "outsourcing" authentication to an unknown third party, the additional complexity muddies the trust relationship between the user and the site owner and introduces new opportunities for hackers to undermine that relationship.

Despite those weaknesses, Mozilla has developed an authentication protocol in Persona that better balances usability, individual privacy, and data ownership than other similar web application solutions. I would encourage any organizations and individuals that desire greater control over online authentication processes to include Persona in their evaluation pool.