|
|
Subscribe / Log in / New account

PyCon: Mozilla Persona

By Jake Edge
March 20, 2013

At first blush, PyCon doesn't seem like quite the right venue for a talk on Mozilla's Persona web authentication and identity system. Persona is not Python-specific at all, but given the number of web application and framework developers at the conference, it starts to become clear why Mozilla's Dan Callahan was there. Python also gave him the ability to do a live demo of adding Persona support to a Flask-based web site during the well-attended talk.

Kill the password

In a nutshell, Persona is Mozilla's attempt to "kill the password", Callahan said to applause. It is a simple, open system that is federated and works cross-browser. Beyond that set of buzzwords, though, the idea for Persona is that it "works everywhere for everyone".

[Dan Callahan]

For an example of using Persona, Callahan visited ting.com—a mobile phone service site from Tucows—that has a login page supporting Persona. Clicking the "Sign in with Persona" button popped up a window with two of his email addresses and a sign-in button. Since he had already used the site before, to log in he just needed to choose one of his email addresses (if he is using a different address from the last time he visited the site) and click "Sign in". It's "dead simple", he said.

Persona ties identities to email addresses. That has several advantages, he said. Everyone already has an email address and sites often already track them. For many web sites, adding Persona support requires no change to the database schema. That also helps prevent lock-in, as sites that decide not to continue with Persona are not stuck with it.

Some in the audience might be saying "I can already log in with two clicks" using a password manager, Callahan said. That's true, but Persona is not managing passwords. There is no shared secret between the site and the user.

That means a database breach at the site would not disclose any information that would be useful for an attacker to authenticate to the service as the user. While site owners will need to alert their users to a breach, they won't have to ask them to change passwords. Better still, they won't have to recommend that the users change their identical passwords at other sites.

If there are no shared secrets, many of the existing account registration questions can simply be skipped. The Persona sign-in process provides an email address, so there is no reason to prompt for that (twice in many cases), nor for a password (twice almost always). For example, with sloblog.io and an existing Persona, he can set up a blog with two clicks.

To prove a point, he was doing his demos from the Opera web browser. Persona works the same in all major browsers (Firefox, Chrome, Safari, IE). It uses existing technology and standards and "works everywhere the web works", he said.

The story behind Persona comes right out of the Mozilla Manifesto, Callahan said. That manifesto was "written at the height of the browser wars" and lists ten points that are "crucial to the open web". Principle #2, "The Internet is a global public resource that must remain open and accessible", is particularly threatened today, while principle #5, "Individuals must have the ability to shape their own experiences on the Internet" speaks directly to the Persona ideal. Nothing is more important to shape one's internet experience than is the choice of identity, he said.

"Single" sign-on

There has been a movement toward single sign-on (SSO) in recent years, but "single" is a misnomer at this point. Many sites allow people to sign in with their Facebook or Twitter (or Google or Yahoo or MSN or ...) account. His slide had an example login with a bunch of login icons for those services, ending with a "Good luck with OpenID" button.

The problem with that approach is that it is like Tribbles (with a requisite Kirk and Tribbles slide); there are more and more of these service-based login mechanisms appearing. How does a site pick the right one (or, more likely, ones)? How does a user remember which of the choices they used so they can use it on a subsequent visit?

He gave another example: the 500px login screen. It splits the screen in half, into two sets of choices, either logging in via a social network (Facebook, Twitter, or Klout) on one side, or with a username and password on the other. If a user wants to use a Google or Microsoft login, they are out of luck. They must create a username and trust that 500px will do the right thing with their password. He was also amused to note that he hadn't heard of Klout, so he visited to see what it was and Klout wanted him to log in using either Facebook or Twitter.

There are also some implications of using the login network of certain services. Google and Facebook have real-name policies that can sometimes lead to account suspension when a violation is suspected. That suspension then trickles out to any other services that use those login mechanisms. Facebook policies disallow multiple accounts (e.g. personal and business) as well. Basically, services using Facebook logins are outsourcing their account policies to Facebook.

It is worth a lot of money for the social networks to get their buttons onto sites, Callahan said. So "any solution has to come from someone outside who is not trying to make a buck off every login". Since Mozilla is on the outside, it is well positioned to help solve the problem.

The earlier Persona demonstrations were for email addresses that had already been set up, but Callahan also wanted to show what happens for users who are not yet signed up. In that case, the user must type in an email address in the Persona pop-up. Persona checks with the email provider to see if it supports Persona, if so the email provider authenticates the user via its normal mechanisms (e.g. web-based login) that the user has seen plenty of times before. If the user successfully authenticates, the email provider indicates that to the site.

Using Persona team members as props, Callahan showed the process. The user claims a particular email address and the site contacts the email provider for verification. The email provider asks the user to authenticate (using a password, two-factor authentication, facial recognition, ...) and if that is successful, the provider signs the email address and hands it back to the site (along with some anti-replay-attack data). The site then verifies the signature, at which point it knows that the user has that email identity.

Implementing Persona

As can be seen, the description of the protocol and cryptography used was rather high-level. Callahan's clear intent was to try to convince web application and framework programmers to get on board with Persona. There is more information about the underlying details at developer.mozilla.org/persona, he said.

For the moment, few email providers support Persona, so as an "optional temporary" measure, sites can ask Mozilla to vouch for the email address. For example, Gmail does not support Persona (yet), but Mozilla can vouch for Gmail users by way of a challenge email. Authenticating the email address to Mozilla need only be done once. But that puts Mozilla in the middle of each initial authentication right now; eventually the user's email providers will be serving that role.

The documentation lists four things that a site owner needs to do to use Persona. There is a JavaScript library to include in the login page, the login/logout buttons need "onClick" attributes added, and the library needs to be configured. The final piece of the puzzle is to add verification of the identity assertions (signed email addresses from the email provider or Mozilla). That verification needs to be done in the server-side code.

In the future, the hope is that browsers will natively support Persona, but for now the JavaScript is needed. On the client side, it is 30 or so lines of JavaScript called from the login and logout paths. The server side is a little more complicated, as assertions are cryptographically signed, but that verification can be handed off to a service that Mozilla runs. The back end just posts some JSON to the Mozilla service and reads its response. Those changes take less than 40 lines to implement.

Using the code directly from his slides, Callahan changed both client and server sides of a demo application. That added the "great user experience" of Persona logins. It also showed an "amazing developer experience" in how easy it is to add Persona. Once the demo was done, and the applause died down, Callahan said "I am so glad that worked" with a relieved grin.

Callahan had three tips for site developers adding Persona support. The first was to make a library specific to the framework being used that can be reused in multiple applications. Second, his example used the Mozilla verifier, but that is not a good long-term solution for privacy reasons. But, he cautioned, make sure to use the Python "requests" library when doing verification as the standard library does not check SSL certificates properly. Lastly, he wanted to make it clear that using Persona did not mean that a site had to get rid of the other login buttons, "just that maybe you should", he said. Persona can peacefully coexist with these other login mechanisms.

In conclusion, Callahan said he had a request: "spend one hour with Persona this week". You could add it to your site in an hour, he said, but if not, just try it out on some site. Persona is still in beta, so it is "able to be shaped by your feedback". Also, he requested, please ask one site that you use to support Persona, "that's how we are going to change the future of the web". Persona will allow everyone—not just the few who understand OpenID or password managers—to have a safer, more secure web.

[ In keeping with Callahan's request, we will be looking into Persona support for LWN. ]

Index entries for this article
SecurityAuthentication
SecurityIdentity management
ConferencePyCon/2013


to post comments

PyCon: Mozilla Persona

Posted Mar 21, 2013 2:54 UTC (Thu) by raven667 (subscriber, #5198) [Link] (12 responses)

The great thing about standards is that there are so many to choose from. In this case we seem determined to re-implement kerberos, again. I'm not sure it's the protocol which is preventing Internet-wide SSO from taking off but other related issues such as service providers not wanting to run any additional services that they don't absolutely have to.

I wish them all the best though, maybe with enough UI polish and ease of integration this will finally happen. SSO won't succeed if we don't keep trying.

PyCon: Mozilla Persona

Posted Mar 21, 2013 3:00 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (11 responses)

Kerberos always was (and still is) a shit. It's implemented in the best traditions of 80-s as a binary protocol with uber-complex spec and lots of gotchas (like time synchronization) for a time long gone by (no support for multiple tickets, etc).

I always wanted to create a simple Kerberos replacement utilizing PKI with signed tokens instead of the central server.

PyCon: Mozilla Persona

Posted Mar 21, 2013 8:46 UTC (Thu) by ersi (guest, #64521) [Link]

Nothing wrong with binary protocols - they have their places as well. It's actually sort of making a come back again. There's trade offs with both binary and text-only protocols of course.

Complex specifications are always quite negative though.

PyCon: Mozilla Persona

Posted Mar 21, 2013 15:26 UTC (Thu) by drag (guest, #31333) [Link] (8 responses)

> I always wanted to create a simple Kerberos replacement utilizing PKI with signed tokens instead of the central server.

Good luck.

Once you figure out how to authenticate both servers and clients using it while having the ability to easily and instantly revoke any ticket or certificate then you'll revolutionize the industry. You name will be written into the stars.

;-)

On the other hand bringing up Kerberos in this discussion is probably inappropriate because it's a different problem domain. Although it seems to work quite well for Jabber servers....

PyCon: Mozilla Persona

Posted Mar 21, 2013 15:42 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)

> Once you figure out how to authenticate both servers and clients using it while having the ability to easily and instantly revoke any ticket or certificate then you'll revolutionize the industry. You name will be written into the stars.
Believe it or not, I've actually thought this part out. Services that want to verify the token presented by a client can just send the client a nonce and wait until the client returns this nonce in a message counter-signed by a trusted authentication server.

This way, services that require authentication do not need to access the Kerberos-replacement server at all. They actually don't even need to have a bidirectional security association with it.

PyCon: Mozilla Persona

Posted Mar 21, 2013 15:48 UTC (Thu) by drag (guest, #31333) [Link] (5 responses)

So how does the client know that they are talking to the correct service?

PyCon: Mozilla Persona

Posted Mar 21, 2013 16:20 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

You still can establish bi-directional trusts, simply by getting service a signed certificate or even asking it to get an authenticated ticket.

PyCon: Mozilla Persona

Posted Mar 21, 2013 19:07 UTC (Thu) by drag (guest, #31333) [Link] (3 responses)

> or even asking it to get an authenticated ticket.

Like from a ticket granting service?

Next thing you'd know you'll be wanting to put timestamps in the signatures so that you can be sure that a attacker wouldn't have enough time to find a weakness and break the encryption before the ticket expires and this way you avoid the overhead of having to maintain a state of all submitted 'nonces' on the server itself.

:P

PyCon: Mozilla Persona

Posted Mar 21, 2013 20:00 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Timestamps are useful, but they are unreliable.

And you don't need to maintain ANY state on the server, the whole protocol can be completely stateless. Certainly, not the list of nonces.

PyCon: Mozilla Persona

Posted Mar 21, 2013 20:29 UTC (Thu) by dlang (guest, #313) [Link] (1 responses)

so how do you know if authentication is being replayed or not?

PyCon: Mozilla Persona

Posted Mar 21, 2013 20:35 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

By using a nonce.

PyCon: Mozilla Persona

Posted Mar 26, 2013 9:36 UTC (Tue) by ras (subscriber, #33059) [Link]

> Once you figure out how to authenticate both servers and clients using it while having the ability to easily and instantly revoke any ticket or certificate then you'll revolutionize the industry.

Persona doesn't do that - it doesn't support revocation. So if you move email providers there is no way to revoke logins using that email address.

Not a problem if you are using your own Email server of course, but if you are using your own server it offers no advantages OpenID, which doesn't suffer from this flaw.

PyCon: Mozilla Persona

Posted Mar 24, 2013 13:05 UTC (Sun) by lukehatpadl (guest, #90013) [Link]

You might be interested in GSS BrowserID. It uses Mozilla Persona to effectively create a Kerberos replacement. (Think of Persona certificates as tickets, assertions as authenticators, and you're halfway there.)

GSS BrowserID adds key agreement, mutual authentication, and fast re-authentication to the existing Persona protocol, and allows it to be used with existing protocols that support GSS-API or SASL (e.g. IMAP, SSH, SMTP, XMPP, CIFS, NFS).

You can read the specification here:

http://tools.ietf.org/id/draft-howard-gss-browserid

Implementation here:

https://github.com/PADL/gss_browserid

PyCon: Mozilla Persona

Posted Mar 21, 2013 8:13 UTC (Thu) by mozCallahad (guest, #89970) [Link] (8 responses)

There's nothing like reading about your own talk via someone else's subscriber link to remind you that you should really get around to subscribing to LWN. Done.

If you folks (or anyone else in-thread) need help implementing Persona, please let me know.

Also, a video of the talk is online at http://pyvideo.org/video/1764

PyCon: Mozilla Persona

Posted Mar 21, 2013 21:03 UTC (Thu) by vdanjean (subscriber, #1552) [Link] (5 responses)

I've been interested when I read the LWN article. Having my own domain with mail and web server, I look at the doc to implement/install the provider part of Persona.
However, I quickly see that the service must be served by a https webserver whose certificate is signed by a list provided by mozilla. And cacert is not in the list. And there is no way to get a useful free certificate. StartSSL ( https://www.startssl.com ) cited in the documentation only issues certificate for *one* subdomain. To get more subdomains in one certificate, 59 US$ is required...

So, I've to choose between:
- pay to get a proper certificate and implement a Persona provider for my emails
- pay to get a new IP where I would put the https server for my root domain
- do not may, keep my free multi hostname cacert certificate that is used for all my https website, and forget being a Persona provider

Until Persona works and is useful on IPv6 only (where I have of course multiple IP), it wont be interesting for me. Unless there is another free multi-hostname certificate provider validated by mozilla (would mozilla validate cacert ?)

PyCon: Mozilla Persona

Posted Mar 21, 2013 21:43 UTC (Thu) by mozCallahad (guest, #89970) [Link]

The CA racket is abysmal, but we have to bootstrap a chain of trust somehow. Does your registrar offer free certs with registrations, by chance?

As far as I can tell, CACert.org withdrew its request for inclusion in Firefox back in 2006, and has not reopened its request: https://bugzilla.mozilla.org/show_bug.cgi?id=215243

PyCon: Mozilla Persona

Posted Mar 23, 2013 3:06 UTC (Sat) by foom (subscriber, #14868) [Link] (2 responses)

You can get an unlimited number of free one-domain certs from startssl.

Plus, you can use as many ssl certs on a single IP as you like using the "SNI" mechanism, as long as you don't care about Windows XP clients accessing your website (WinXP doesn't support SNI).

You (assuming you're running a relatively modern copy of Apache) you can simply put different SSLCertificateFile, SSLCertificateKeyFile, and SSLCertificateChainFile config lines within each <VirutalHost *:443> stanza, and Apache will automatically use SNI to choose the one for the domain name provided by the client.

That's what I do on my personal server, which serves three different domain names. It works great. I do the same thing with dovecot, for IMAP and POP connections.

PyCon: Mozilla Persona

Posted Mar 23, 2013 3:14 UTC (Sat) by foom (subscriber, #14868) [Link] (1 responses)

Oops, I hadn't seen the note that says that Persona doesn't support SNI yet (come on, seriously?).

So, yea, until that critical bug is fixed, it's a pretty crappy situation.

PyCon: Mozilla Persona

Posted Mar 23, 2013 16:25 UTC (Sat) by raven667 (subscriber, #5198) [Link]

Also, what about IPv6 support, especially for the fallback infrastructure. login.persona.org doesn't seem to have a AAAA DNS record.

PyCon: Mozilla Persona

Posted Mar 23, 2013 22:34 UTC (Sat) by akumria (guest, #7773) [Link]

You information about StartSSL might be outdated.

I've had, and continue to have, certificates from them issued for many hosts and many domains.

It might be wortwhile checking again.

PyCon: Mozilla Persona

Posted Mar 22, 2013 15:57 UTC (Fri) by kh (subscriber, #19413) [Link] (1 responses)

Have you approached zimbra (or similar) about integrating Identity Providers (IdPs) support?

PyCon: Mozilla Persona

Posted Mar 23, 2013 0:28 UTC (Sat) by mozCallahad (guest, #89970) [Link]

Not yet, but if you know any developers on the Zimbra or related teams, I'd love to chat with them.

PyCon: Mozilla Persona

Posted Mar 21, 2013 9:40 UTC (Thu) by djc (subscriber, #56880) [Link] (1 responses)

Persona is very awesome. I implemented a Relying Party implementation for one of the small community sites I run, and it was very easy.

I also implemented my own Identity Provider using Google Authenticator-compatible TOTP, find the code here:

https://bitbucket.org/djc/persona-totp

Needless to say, I'd very much like for LWN to implement Persona RP support!

PyCon: Mozilla Persona

Posted Mar 22, 2013 15:52 UTC (Fri) by kh (subscriber, #19413) [Link]

Yes, I am looking forward to reading the article about implementing it for subscribers to the LWN website, as well as the article about setting up their LWN email domain to be a Identity Providers (IdPs) for their own staff with a lwn.net email address. 8-)

PyCon: Mozilla Persona

Posted Mar 21, 2013 10:49 UTC (Thu) by jezuch (subscriber, #52988) [Link] (4 responses)

> The email provider asks the user to authenticate

I hope this doesn't assume that everyone uses webmail. I haven't logged into my email provider's site in years and for a moment I wasn't sure I remembered the password ;)

PyCon: Mozilla Persona

Posted Mar 21, 2013 11:26 UTC (Thu) by anselm (subscriber, #2796) [Link] (3 responses)

If I have understood this correctly, nothing in Persona requires the »e-mail address« you use to authenticate to be an actual e-mail account that can send and receive messages. It is basically a fancy user name where the domain part tells Persona which server to contact to do the login. If you have a web server with your own domain you could in a reasonably straightforward manner set up a Persona identity provider that is in no way connected with e-mail.

The trouble starts when the web site you're authenticating to assumes that the authentication »e-mail address« actually works as an e-mail address to send stuff to. Again, if you have your own domain and can arrange for messages to that domain to be accepted or forwarded this isn't a big problem, but it's worth keeping in mind in general.

I'm not convinced that the Persona method of (ab)using e-mail addresses as login names is a brilliant idea – it is enticing at first glance but it smells a bit like using SSNs for »authentication«. The other snag is the current requirement for HTTPS-without-SNI; we have a mail server that accepts e-mail to a large number of domains, and while supporting Persona as the authentication provider for these domains would be useful we don't have the IP addresses to go around to give each domain its own HTTPS server.

PyCon: Mozilla Persona

Posted Mar 21, 2013 12:59 UTC (Thu) by nim-nim (subscriber, #34454) [Link]

At work (bigcorp > 100000 users), we had an ldap server that accepted email as identifier for years. It was great from user experience at first. Then people started to create fake emails for persons that needed an id but had no corporate email account. From then on it quickly spiralled into management hell.

Apps were routinely confusing email with email-as-login, notifications were getting lost, support had no way to reach users that were registered in apps with a fake e-mail, tracability got lost with users that used a group email alias as login…

The next implementation got rid of this concept altogether

PyCon: Mozilla Persona

Posted Mar 21, 2013 17:49 UTC (Thu) by mozCallahad (guest, #89970) [Link] (1 responses)

We're tracking the SNI issue here: https://github.com/mozilla/browserid/issues/2583

It will likely be resolved once we move our infrastructure to AWS (by summer, probably?) -- the one caveat is that SNI does not work with IE8, so relying on SNI will lock those users out of your domain.

PyCon: Mozilla Persona

Posted Mar 9, 2014 12:39 UTC (Sun) by hkario (subscriber, #94864) [Link]

IE 8 does support SNI, Windows XP schannel doesn't support SNI

If you're running IE (any version) on Vista or 7 you do get SNI.

PyCon: Mozilla Persona

Posted Mar 21, 2013 12:59 UTC (Thu) by Seegras (guest, #20463) [Link] (5 responses)

What about people running their own mailservers? Where's the support for that? Exim? Postfix? Dovecot? No bloody Webmail?

PyCon: Mozilla Persona

Posted Mar 21, 2013 13:24 UTC (Thu) by mpr22 (subscriber, #60784) [Link] (1 responses)

From the FAQ: "If a domain is not a native Identity Provider, and thus can't verify its own users, the browser asks for verification from Persona's fallback Identity Provider at https://login.persona.org. Before certifying a user's identity, the fallback Identity Provider does test the address by sending an email to it and asking the user to click a link contained within."

PyCon: Mozilla Persona

Posted Mar 21, 2013 15:56 UTC (Thu) by drag (guest, #31333) [Link]

I like the idea of buying my own domain and then being able to use/abuse it to provide all the authentication I need for the web.

PyCon: Mozilla Persona

Posted Mar 21, 2013 14:32 UTC (Thu) by intgr (subscriber, #39733) [Link] (2 responses)

Where do people get this crazy idea that Persona requires webmail? The fallback version sends you a frickin' email with a link in it. Even if you read your email with POP3+netcat you can copy-paste the link out.

If you want to run your own identity provider, you have to run a web server supporting the Persona protocol. Nothing to do with webmail (and not necessarily even email).

PyCon: Mozilla Persona

Posted Mar 21, 2013 17:51 UTC (Thu) by lbt (subscriber, #29672) [Link]

Since you asked then they probably got the idea from reading the article:

"the user must type in an email address in the Persona pop-up. Persona checks with the email provider to see if it supports Persona, if so the email provider authenticates the user via its normal mechanisms (e.g. web-based login)"

Maybe our editor could help clarify that : "For situations where the provider does not support Persona (eg for personal domains) then there is a fallback mechanism discussed in more detail below."

PyCon: Mozilla Persona

Posted Mar 21, 2013 18:23 UTC (Thu) by mozCallahad (guest, #89970) [Link]

> Where do people get this crazy idea that Persona requires webmail?

Honestly, that's probably my fault. Webmail is the common case, so I have a tendency to use language around that in my examples.

You don't have to use webmail. You don't even have to have a routable email address. You *do* have to authenticate in a web dialog, but the contents and mechanism of that dialog are completely up to each domain.

PyCon: Mozilla Persona

Posted Mar 24, 2013 14:50 UTC (Sun) by kleptog (subscriber, #1183) [Link] (1 responses)

There is an unfortunate trend for site accepting OpenID providing only icons whereas you should be able put any valid OpenID. Besides that though, persona seems to me to be a variation on OpenID where an email address is used for the identifier and there is some browser support.

And given that Google does support OpenID, wouldn't it be possible to create a gateway to allow google users to use persona by authenticating them with OpenID?

PyCon: Mozilla Persona

Posted Mar 25, 2013 15:00 UTC (Mon) by wookey (guest, #5501) [Link]

I never worked out how to provide my own openID server. There never seemed to be an apt-get install openid-server package to help. It sounds like persona is more doable for those of us with our own domains/servers, except for the annoyance that cacert _still_ isn't in the mozilla CA list. This affects a lot more than just persona.

Anybody making a persona-server package to help with painless set-up?

I never understood why openid didn't solve this problem last time round, except possibly for the same reasons that I could never work out how to vouch for myself, so maybe the rest of the net had similar problems.

The problem does badly need fixing fixing as one is increasingly often given the choice of logging in with either twitter or facebook, which (at least for me) is a fat lot of use. Are the sites doing that likely to start offering persona? Why should they? (I mean we know why they _should_, but what incentives do they have to actually do it?).


Copyright © 2013, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy