Hacker News new | comments | show | ask | jobs | submit login
Persona is distributed. Today. (identity.mozilla.com)
573 points by charlieok on Mar 26, 2013 | hide | past | web | favorite | 147 comments

I've just read through the Persona protocol specification document at https://github.com/mozilla/id-specs/blob/prod/browserid/inde... and was quite disappointed to find RFC5785 in use, in which HTTP is abused as an infrastructure discovery protocol.

This gives a lie to the identity being an "email address". It isn't. Ok, it's structured as a LHS@RHS form but the domain in the RHS isn't an email domain, it's an overloaded website with some problematic assumptions ladled in.

This creates a significant barrier to adoption. Many entities just won't bother: not only does it ask an apex A record to serve actual content (usually a mistake) but it requires the primary web host of a registerable domain, usually a trademark or brand identity, to carry technical material, definitely a clash of concerns.

(Why? In many companies of reasonable size, the website is managed by a completely different group of people - often a marketing team - to the internal identity service. Then, even if one team convinces to the other to install the browserid file, there is a possibility of it being deleted it by mistake during the next site refresh.)

I had hoped to find an intermediate step where a DNS SRV lookup was used to first locate the host delivering the browserid file. This follows the federated structure of email rather more closely and allows the identity service to be independent of the corporate brochureware. Even better - if the SRV lookup could be signed with DNSSEC, the transfer itself can be protected with DANE. The whole thing becomes manageable as a simple, separate unit of technology. It is thus rather more likely to gain the support of system administrators.

We're discussing the addition of a DNS discovery option. Not clear yet that this is something that can be secured as well as HTTPS discovery (which I don't consider abusive, given the number of systems that do it already.) But it's on our radar: https://github.com/mozilla/browserid/issues/1523

But requesting a resource without knowing it exists is abusive, and the fact that more and more developers think it's an appropriate means of discovery is becoming a serious problem. It saps resources, fills logs with noise, and can trigger intrusion detection systems.

I don't think the Persona project recognizes what a barrier to entry the lack of a reasonable discovery method really is. There are a host of potential issues:

1. For the alice@example.com identifier, it assumes that example.com has an A record. Many, many organizations choose not to have an A record at the top level, while still publishing an MX record to support email addresses.

2. If there is an A record, it assumes that there is a web server listening on port 443. If there isn't, /.well-known/browserid can't be retrieved. What is the fallback mechanism, and how does it affect our users if we adopt Persona in the future? What if this probe is flagged by an IDS, blacklisting the source IP?

3. If there is a web server listening on port 443, it assumes that it will serve resources for example.com. What if it doesn't and gets the /.well-known/browserid from the default host, which is an entirely different domain? What if this probe for an unsupported host is flagged by an IDS, blacklisting the source IP? What if example.com isn't the CN or a SubjectAltName in the SSL certificate? Is the certificate validated? Do I now have to purchase a commercial certificate for a domain that I never intended to be a web site?

4. When a user first enters an identifier, such as alice@example.com, it assumes this is not only a valid email address, but a valid login. What happens if a user has used an email alias in the fallback that cannot be used to authenticate in our system when we adopt Persona? What if the organization doesn't support Persona, and doesn't want its domain used in the fallback mechanism? Is there an inherent identity theft risk in using a fallback system? Can a rogue web developer create a temporary /.well-known/browserid and backend that will allow them to authenticate as anyone at the organization, then cover their tracks by removing the file?

All of these issues can be neatly solved with DNS discovery. If an organization wants to support Persona, let it publish an SRV record. If one doesn't exist, Persona should tell the user, "Your domain does not support Persona."

The are all good arguments, and again I want to point out that we are considering them. But there is a big security concern with DNS spoofing (and DNSSEC is not quite easy yet.) So it's not an obvious decision.

On top of the arguments of jackalope, I would like to add one more.

For many domains, the A record do not go directly to the actually webserver of the company. Many domain has redirects for SEO reasons, and often get this services directly by their DNS provider (and often do not allow https). Persona prevents this kind of setup. I am also a bit curios if a certificate under one domain can verify a email user of an different domain.

The DNS spoofing threat already existed; you have TLS as a partial mitigation. DNSSEC w/DANE is a better mitigation. (Ok, plenty of warts in DNSSEC but it is available today). I'd be more worried about the malicious web developer threat - it's almost trivial to exploit.

Generally - if one is going to throw around the word "federated" but without properly leveraging the DNS, then the wheel is probably being reinvented; along with a host of layering violations that result in the many misbehaviours discussed here.

The absence of SRV lookup capability in Mozilla is open issue (bug #14328) since 1999.

The identity indeed doesn't have to be an email address; I'm currently using a random thing I set up on AppEngine's free tier (serving a static file for the public side; the auth side is client-local). There's no way I'll be receiving @*.appspot.com mail. Of course, this also means my identity is tied to a domain I don't control and might go away at any point with no warning...

I do think that the Persona developers are conflating identity with e-mail too much; I can't use it for Mozilla's bug tracker, for example, because I actually value receiving mail and they have no plans to have split identity/e-mail information.

>This creates a significant barrier to adoption.

No, not really. Because Mozilla is running the Fallback server in the meantime.

On the contrary, it means that companies (already deterred by the technical issues) don't even have to bother. It's actually another barrier to entry, only more subtle. It's an incentive not to bother deploying an IdP, which is the adoption I'm talking about and that is necessary to call it "federated". One might liken it to government subsidies for the incumbents in an industry.

There's no "meantime" here - unless a Very Large Social Network adopts this protocol, I suspect the Fallback server will be the IdP most people use.

Even worse, Persona promises that "Developers get a verified email address for all of their users," which might be mistakenly construed as some degree of identity assurance, which can't be guaranteed by this system at all, especially when a fallback is involved.

Can JavaScript look up a SRV record?

Javascript can (ISTR there is a pure JS DNS library for node) but perhaps not in the browser without specific browser support. You can say the same about trustworthy crypto, incidentally.

SRV is definitely the ideal record. In this case I can see why a pure HTTP approach was chosen (it avoids browser dependancies) and it irks me that developers of web-based tools tend to develop inside the HTTP bubble rather than using the broad and highly capable infrastructure of the Internet, because this kind of constraining outcome is the result.

SRV would be an excellent choice for HTTP/2.0 as well, rescuing us all from apex quasi-CNAME hacks and the like.

However in my initial remark you can substitute in the use of "a well-known subdomain"[1] for "SRV record" and still achieve a better separation of concerns than simply using the RHS of the identity string.

[1] c.f. DKIM's slightly hackish but effective use of an intermediate underscore to denote infrastructure DNS entries. Won't work for A records though IIRC.

Only with the help of a server.

I agree. To me, Webfinger+OpenID seems like a more sensible solution. At least in principle. The only downside is that OpenID lacks BrowserID's privacy bits.


> The only downside is that OpenID lacks BrowserID's privacy bits.

Well, that's quite a major downside, don't you think ? Isn't one of the main purpose of persona/BrowserId a better respect of privacy ?

I believe http://gpgauth.org/ is better (except that it lacks strong community and PR from browser vendors).

No need for per-site passwords (the only passwords are master password and, possibly, secret for key escrow). No need for any discovery and third parties, as you're identified by your own key, which contains a name (or nickname or whatever) β€” the most natural approach to identities (which has minor problem with nickname collisions, but that's about it). And, privacy-wise β€” no need to reveal email address if you don't want it, too.

Edit/Add: WebID looks even more nice http://webid.info/, as it's actively developed by W3C WebID Community Group, while gpgAuth development is stalled and project seems dead.

Wow, I remember reading about foaf+ssl years ago. Glad to see it's still alive!

How is this different from OpenID?

EDIT: Seriously, this question was downvoted within two minutes? Why?

EDIT again: The best I've been able to come up with by reading the comments and docs is that they attempt to solve the same problem, but OpenID is based on the backend of the website you're logging into issuing a request to the auth server over HTTP, while Persona has the auth server issue a very-short-duration cert for a public key generated by the client.

Ben Adida, one of the developers, wrote a post on the subject here: http://identity.mozilla.com/post/7669886219/how-browserid-di...

In short, three big differences:

1. Identifiers are email addresses, not strange URI things, which is good because users are already comfortable with emails identifying them.

2. Privacy: Your OpenID provider can see what services you log into. Not true with Personas, which was a big deal for Mozilla and for me.

3. Browser integration: The APIs are currently implemented with a javascript shim, but the browser can step in (either via native support or an extension) to provide new, exciting types of authentication -- dongles, certificates, interpretive dance via a kinect, etc.

How does Persona avoid the identity provider seeing what services you log into? (Assuming the provider has implemented the distributed version of the protocol, not Mozilla's fallback IdP)

The service you log into knows the identity provider's public key and a cert for the user (the user's public key signed by the identity provider).

The service can verify the user's cert against the identity provider's public key with this information. The service initially contacts the identity provider to get the provider's public key, so the identity provider can infer that someone is attempting to log into the service as one of its users.

Once the service has the provider's public key, it can be cached by the service until it expires, and while it's cached, the service can verify logins without contacting the server again by checking that the cert presented by the user to the service has a legitimate signature from the identity provider's public key.

So if someone logs into HN using their Gmail ID (assuming both services grow support for the protocol), all Gmail knows is that at least one person attempted to log into HN using a gmail address. Who was trying to log in, whether that login was successful, and the number of other people who logged into HN with Gmail after that, are all facts that would be completely hidden from Google.

Does this mean that your browser can cache the signed cert and log in to websites automatically without needing to even contact the provider again?

I'm guessing there's some sort of timestamp there, to prevent someone from just stealing the cert and logging in to whatever they want as that user.

Yes, that is exactly right, and it's also why certs are short-lived (hours). When certs are renewed, the site the user plans on logging into is not revealed to the Identity Provider.

By my understanding, yes and yes. The third-party service caches the public key (with timestamp) and the browser caches the signed certificate (with timestamp). The timestamp gives the credentials a relatively short TTL to prevent a stolen cert from being used indefinitely.

not different from someone stealing your cookies.

Cookies can be invalidated. Signatures, not so much.

It's possible to revoke a certificate. Not sure if that's what you're supposed to do in this case, but it's possible.

This is an incomplete definition of privacy. If the service and server collude, you are hosed. There are cryptographic constructions(anonymous credentials) that have been around for over a decade that prevent this. IBM and Microsoft both have (unfortunately incompatible) libraries that do this. If we really are trying to build the id scheme of the future, why not use these?

Can you provide links?

Sure, though unfortunately I know of none that provide a decent balance between high level explanations and cryptographic depth.

The main actual deployed usage of the technique is in TPM's for direct anonymous attestation. http://en.wikipedia.org/wiki/Direct_Anonymous_Attestation

IBM explains their project here http://www.zurich.ibm.com/idemix/details.html

The original academic work its based on is this http://cs.brown.edu/~anna/papers/cl01a.pdf

A different(and older) technique which, by my understanding, is mainly useful for smart cards, is deployed in a prototype system from microsoft : http://research.microsoft.com/en-us/projects/u-prove/


In short, your browser asks the identity provider to sign a certificate proving that you are someone@example.com. The browser will then use that certificate to authenticate you on the site. The site can check this certificate by getting the pubkey from the identity provider. You are never associated with the site you are authenticating against (except on very low traffic identity providers)

Check out around the 16:00 mark in this video: https://www.youtube.com/watch?v=nJff23UdNAI

Notice that provisioning (steps 1 and 2) and logging into a site (steps 3 and 4) are two completely independent processes, with the browser mediating any identifiable identity-provider-to-target-site communication.

Persona stores a signed statement from the IdP in your browser (currently using localStorage). Once you get the statement from your IdP verifying your identity, you can log in using the same proof many times without contacting the IdP, until it expires.

In brief, Persona offers a dramatically better privacy model, developer experience, and user experience. The protocol is decentralized and designed from the ground up to be built into the browser natively.

Re: Downvotes: It's a pretty common question that we (the Persona team) have clearly not done a good enough of a job of communicating. I imagine a lot of folks here are just tired of the repetition.

>It's a pretty common question that we (the Persona team) have clearly not done a good enough of a job of communicating

It would be nice if you created a example Persona-enabled web application (some lines of gulp PHP or heck even a VirtualBox image), push it to bitbucket/github/whatever and link to the repo from http://www.mozilla.org/en-US/persona/. Does not need any functionality, just a login screen using Persona and a "it works" page you reach after logging in. And maybe sample ID provider code too. Extra cookie points if the "it works" page explains the structure of this Proof of Concept application and how the Persona protocol was used.

This way, a curious developer could pull the source, have a Persona-enabled template app and his own ID provider up and running in minutes and could play around with it, evangelize it in his organization etc. If it "feels" right, said developer would read the docs afterwards to move beyond the Proof of Concept.

That sounds like a great idea. We could probably build something similar on NudgePad.com (YC, WebFWD) so interested folks could quickly have a forkable, runnable Persona sandbox.

Look for it soon. :)

Great, thanks :)

Persona allows you to keep your network activity private from providers. It's the same in a couple of important aspects, though:

1. You still have to remember which email you had used to login. This was heavily criticized with OpenID ("did I login with Google or MyOpenID?" kind of situation). With emails it just got worse, as you will have problem, especially if you're trying to fight spam using service-specific emails (hackernews@foo.example.org).

2. You still can't "migrate" from one email address to another. Shall your email provider go down or you lose your domain - you lose your identity.

3. You still don't own your own identity. The identity is just leased to you by your email provider (or your domain registrar).

Firefox supports Persona and they're not going to support OpenID.

It's worth pointing out that, a couple of years ago, we tried to make OpenID easier through Firefox integration. There was no good way to do it. The OpenID protocol doesn't lend itself to browser mediation. (In addition to the other usability and privacy problems mentioned above.)

Can you elaborate on that? OpenID was designed to be browser-independent. Persona is essentially a distributed openID with some extra browser integration. Sure Mozilla doesn't support openID, but I'm unsure what you would want them to do...

Without browser support, you have to type your ID into every site. (I'm ignoring Nascar login because that's not distributed.) With browser support you just click to login and maybe click again to confirm.

Here is a Firefox add-ons to add the missing "browser support":


(I have not actually tested this add-on myself.)


While the goals are similar, the ways differ. With perosona, the focus is on emails as the identifier. In case of OpenID, the identity provider may or may not have used email id as identifier.

Nobody should be downvoted for simply asking a question so I upvoted you.

Hope it helps a bit.

EDIT: And somebody downvoted this comment. Oh no, I lost 1 HN point! What . will . I . ever . do?

vitno posted their original blog post explaining the difference, and now it's in their FAQ:


You may also wish to take a look at the Mozilla Persona Developer FAQ:


It's easier for users since it relies on email addresses instead of a URL, easier for developers thanks to its simple API, and tracking information is never leaked back to the identity provider.

I didn't downvote it but I think I know why: there's a huge wave of negativity on HN and your question sounds like criticism.

There are ways to formulate the same question which would be much nicer and less negative, for example:

"It's great to see other solutions providing things similar to OpenID. Can anyone explain what are the differences with OpenID?"

Simply writing: "How is this different from XXX?" just sounds rude and negative.

Understand where you are coming from but this is an overreaction. An HN where you have to wrap a plain, absolutely neutral question like this in a bunch of false praise or meaningless filler words is a much much worse place than the HN that might be overly critical/negative by default (and this perception is partly false, reinforced by the cultural belief that questions are attacks).

On the other hand, paraphrasing what you've said to make a counter-argument: an HN where a peaceful, respectful atmosphere is sustained by thoughtfully worded comments is a much much worse place than an HN where dry, hastily worded comments take some heat.

> thoughtfully worded comments

That's what makes me disagree. I want honest comments and thoughtful reading.

To break that down further:

We have a comment "How is this different from X?" which can be interpreted literally, as an honest question, or with the assumption that what he actually meant is "This is stupid because we already have X".

One solution is to encourage people to write "No offense to the project, It looks interesting but I honestly don't know what differentiates it from X, and if you could explain it in contrast to X I will understand it better since I already understand X"

That's ... ok, but the writer will never anticipate every possible misinterpretation so you will have verbose comments full of fluffy meaningless language and still have the same problem.

The alternative is encouraging people to think about the phrase "benefit of the doubt", what it means and why it's a well known phrase in the first place.

If someone asks "How is this different from X" then you take it to mean what it says, you don't try to guess at what possible negative thing he might have meant. So the replies would all take that comment seriously.

What's the downside? Someones snarky comment would be read as honest and there would be an answer. Who's going to reply with "I actually meant that sarcastically"? Some people might, but they'll just look foolish.

If the choice is between:

1. encouraging a culture where questions are taken as honest questions or 2. one where every question is scrutinized for the slightest possible clue of hidden negative meaning and you have to fill your comment with false praise and legal and marketing language to avoid any possibility of the suggestion of offense

Then the answer is obvious to me.

Honestly, I'm not sure if your counter argument is intended to be ironic.

I'm used to an Internet where you're not required to be so goddamned polite. Seems to me it becomes the spidery veneer of Silicon Valley networking; insincere, self-interested, and a corruption of what it means to be 'nice.'

What's wrong with being polite? It doesn't cost any extra and there are a lot of people who appreciate it.

Not anything wrong with being polite. Plenty wrong with requiring people to be polite.

You're not required to be polite, but you may be downvoted.

shrug yep. I'm saying more that there can be an atmosphere of required politeness.

I mean, look; the OP asked a really good, terse question and got downvoted presumably because it was 'rude.' That's just silly.

I'm curious how the GP's question can be construed as "good" when there exists a blog post that explicitly addresses it. This indicates the GP didn't do even cursory research to determine the answer for themselves. In other words, the GP was lazy, expecting to be hand-fed, and was down-voted as a result.

Ah! If he was downvoted for asking an easily google-able question then that's reasonable and end of discussion.

The discussion here started because of the statement that he was probably downvoted because "how is this different from X?" is interpreted as "This is stupid, we already have X."

For better or worse, the former is what HN usually seems to be. I remember when I started using the site, I spent several weeks learning to write in the fashion of the former to avoid all the negative reactions.

"How is this different from XXX?"

That just sounds like a direct question to me - not rude or negative.

"It's great to see other solutions providing things similar to OpenID"

I don't see what that adds - everyone reading this already knows it is a solution similar to OpenID so why restate it?

Note that I also apologise if you think this reply is rude - I'm really not meaning to be.

Simply writing: "How is this different from XXX?" just sounds rude and negative.

It reads like a perfectly reasonable question to me. Where exactly are you finding rudeness and negativity?

One way it'll be different is (presumably) users won't be confronted with a wall of possible OpenID providers.

You asked a good question. HN's not very good at self-regulating. Negativity is regarded negatively in some bizarre self-perpetuation cycle.

Exactly right: we hate the NASCAR array of buttons that is publisher-centric, rather than user-centric. I wrote about this a few days ago on the Persona blog:


I haven't look at the specs deeply, but it would be nice to have a system that did not need any kind of server at all, but the browser itself could be the Persona identity provider. The actual local data needed to pull it off could be replicated (encrypted) to cloud storage so it would work across all your devices and browsers, but the actual profile data itself would never be readable by the servers.

I started looking at the feasibility of building something like Persona into a 'serverless' social network a while ago using Broadcast Encryption techniques to define social sharing groups with revocation (de-friending) and Identity Based Encryption, but it seems like the state of the art IBE always requires a trusted server somewhere. But someone with more expertise in cryptography than me can maybe make it work. My original essay that prompted it (http://timepedia.blogspot.com/2008/05/decentralizing-web.htm...) based on the sad state of affairs these days where everything is non-federated.

That would end up requiring your identity to be a key of some sort, though, since ultimately the thing you're logging into needs to check _something_. Email-like things are useful because somebody has to control the domain; if you don't have that, it's harder to establish something. Of course, you can say things like "Hi, I'm random prime number 534473", but that's much less memorable...

The displayed name is a bit different concept from identity. It's like a server and it's DNS name.

The point is, nothing prevents the site from knowing me as 70BD6432E50DFB65FF679B32364C3C7840DE4453, but displaying me everywhere as "Aleksey".

there is webid: http://webid.info/ which is like ssh keys for the web.

Isn't this the ultimate goal of Persona - native browser support?

Currently wondering the most sensible approach to make a single-user website support this protocol, so that I can make my email address (the only valid email address at my domain) support Persona natively. I don't really want to have to set up a username/password system with a single user. I'd almost prefer to manually hand my identity's private key to each browser I want to use. I wonder how much work it would take to write a Firefox extension that does this and uses Sync to snychronize the key between browsers?

I recently set up my personal domain as an identity provider, using static HTML/javascript files and a bit of crypto:

There are some things to be mindful of w.r.t. security in this approach, but it seems to work very nicely for me.

This is a ridiculously helpful blog post and it's right up my alley. I have a single-user (vanity) domain, and hate futzing with databases.

The those that haven't read this link: his implementation is done 100% with static files. Clever and looks secure enough to me (though I'm no crypto guy).

I have a Firefox extension that does this: https://github.com/mook/browseridp It only requires a static file; currently I have it hosted on Google AppEngine's free tier. Since it stuffs the keys into the normal password storage, sync should just work.

Didn't take all that long, I guess. See commit log :)

It seems all required is publishing a `/.well-known` URL that delegates to another provider, although it's not obvious if such a provider exists yet.

Pretty cool it's this straightforward, though.

I don't want to delegate to another provider, though; I'd like to take advantage of the decentralized approach, and authenticate my own email address.

What is your preferred server environment? This would be a fun project to whip up quickly.

Static files. :)

Hence the idea of just pre-generating the key pair and sharing the key with my browsers via Firefox Sync.

The provisioning and signin pages could point to static pages that just say "If you're seeing this, you're trying to authenticate as me and you aren't me; go away."

OK, so I can see this working with a browser extension. Throw a pregenerated cert into localStorage and sync across browsers. Where I'm still fuzzy is if the site performs local verification, or login.persona.org does it, it might contact your server to grab its pubkey over SSL, requiring you to host something on your email domain.

> Throw a pregenerated cert into localStorage and sync across browsers.

Browser extensions use their own secure storage mechanisms, not the localStorage used by sites, but yeah.

> Where I'm still fuzzy is if the site performs local verification, or login.persona.org does it, it might contact your server to grab its pubkey over SSL, requiring you to host something on your email domain.

Ignoring the workflow for domains without native identity providers (for which persona.org does its own mail-you-a-link validation), only one thing happens on the server accepting Persona: it requests the public key from the email domain. The site then expects to receive a message from the browser that chains back to that public key. So, you'd have to post some static files to /.well-known/ on your email domain, but the browser extension would construct the signed messages because it has the private key.

You could do this in two ways. For domains completely owned by the user, you could let the browsers hold the domain private key, and mint arbitrary identities on that domain on demand. For domains with multiple users but still wanting to statically manage identities, you could statically generate public/private keys for users and sign them with the domain key, then let the browsers hold onto the email keypairs only.

This sounds awesome. I hope you do it and write a blog post about it!

Check out this comment from a prior article on the subject: https://news.ycombinator.com/item?id=5410576

He's using mobile authenticator as a password mechanism, but it should be modifiable to just trust the local browser.

Outstanding work, Mozilla. Parallel to when they broke the I-E monopoly, Mozilla is truly impressive lately.

Best way to support the new creativity surge by Mozilla - re-adopt Firefox as your MAIN browser.

With each search worth $1 (approximately), every time you search using Firfox, Mozilla receives $1. (payment by Google, for using their search engine)

Mozilla currently receives $300 million/year via search. Increasing search $ income ... rewards Mozilla as the most open platform and amongst the most innovative organizations on Earth.


Another good way to help Mozilla make the Web better for all is to implement Persona on web sites you build. It's easy and respects your users. Here's how you can do it in an hour or less:


Studying, understanding, and maybe implementing this looks like a fun weekend project. Thanks!

Email has been the identity backbone for a long time. Persona supports multiple emails. This makes maintaining multiple identities even easier. A great alternative to identity trackers.

Great work Mozilla team, very eager to see this catch on in the coming years. Would be great if startups could get on board with it so the larger giants will be swayed to follow suit.

I still have a funny feeling about the robustness of Persona. For instance - let's say one of my emails gets hacked, my crappy Yahoo email. Does that give them access to my other Persona accounts? Would I (or anyone else) be able to know if the account is compromised? Normally you change your password and that's the end of it, but I'm not sure what happens with Persona.

What if my kid brother uses my computer - wouldn't he have access to any site that allows Persona logins? How do you lock it down?

> Does that give them access to my other Persona accounts?

No, it gives them access to whatever site you registered with your Yahoo! account. (EDIT: If you use the temporary bridge they implement, they could get access to your other accounts if they got access to the bridge. This won't happen if your email provider supports Persona natively).

> Would I (or anyone else) be able to know if the account is compromised?

Yahoo! probably would, and could tell you.

> Normally you change your password and that's the end of it, but I'm not sure what happens with Persona.

You change your password and that's the end of it.

> What if my kid brother uses my computer - wouldn't he have access to any site that allows Persona logins? How do you lock it down?

Just log out of your email provider.

Really, Persona is just a way to make your email provider your authenticator. It's "Facebook Connect" for your email provider.

Security-wise, if your email gets hacked, what happens is what would happen anyway, since almost every site can request a password reset by emailing you. The attacker has access to that anyway. Persona removes the hassle of remembering one password per account by letting the site ask your email provider if they know you.

Just log out of your email provider.

Really? Is this enough? Elsewhere in this discussion, mention is made of delegating to a different Persona provider. How will your browser (which, near as I can tell, is directing traffic for this protocol, either natively or through an extension) know that clicking "log out" on an email app should make it stop using certs associated with a different Persona app? Even if it were the same provider, perhaps under a different subdomain, this link between email app and everything else seems pretty tenuous. I think there should be an obvious switch to throw in the browser.

Perhaps I'm really misunderstanding things; please advise.

It's the same as Facebook Connect. Logging out of Facebook doesn't log you out of all the connected sites, but it does prevent you from logging in to others, which is what the GP was asking.

That is not my interpretation of the original question, but thanks for clarifying.

This discussion points to a potential for a sort of confusion we've seen before. It used to be a big user education problem to get all users to press the "log out" button when they were done using a site, especially on "public" computers. To some people maybe this is still a problem? (Actually, before that it was a bit of a struggle getting sites to implement "log out" functionality, and we just had session cookies multiplying everywhere.)

If my browser has stored Persona certs associated with various sites but gives me no visual indication of that, it's very possible that I might become confused about where and whether I'm logged in. The various sites to which I'm logged in might have different requirements for auto-logout, etc. It seems that Persona is trying to ignore these issues a bit by saying "this is just for low-value authentication", but fixing the problem seems possible. Incorporating Persona functionality into the browser should allow better security notifications than are possible just through HTML/JS/CSS from individual sites. The user should have the option to easily throw away certs (i.e. without clicking through a bunch of "Settings" dialogs), and should have the information she needs to know when to do that.

Oh, yes. Persona now integrates with logouts as well, so they know when you click "log out" from a site and the user agent can prompt the user to log out of Persona completely or just that site. I don't think they can tell every site you're logged into to log you out by logging out from one site, though.

That's really interesting. I had previously assumed that the stored cert was per-user and available for many sites, with each site using its stored cert from the Persona provider to validate the user cert from the client. (I'm not sure why I assumed that.) Now I see that it's per-user and per-site. The more I learn the more I like Persona.

Ah, thanks for those answers.

You are very welcome!

It's hard not to respect Mozilla in 2013. I know i've personally moved away from Chrome back to FireFox. Mozilla seems like a young Google in a way.

Agreed. I feel like Firefox has become the old Chrome (fast, reliable) and Chrome has become the old Firefox (slow, unreliable, ugly[1]) lately.

[1] Chrome still looks quite decent as of right now but the new UI changes on its beta build makes no sense at all and looks flat out ugly (http://googlesystem.blogspot.com/2013/03/chromes-integration...).

Same here, switched to Aurora permanently and haven't had any issues. Like that it looks native to the OS you are using. And had forgotten how much better the awesomebar is.

Thanks for sharing, did not realize ver20 was in testing.

http://www.getpersonas.com/en-US/ I have been confused by the distinction between these two for the longest time, and I'm hardly alone. Any plans to rename one or the other?

The plan was to deprecate personas as a name for background themes.

https://addons.mozilla.org/en-US/firefox/themes/ doesn't use the word "persona" anywhere I can see any more.

I don't know why getpersonas.com hasn't been axe-murdered yet. (Edit: info on migration is here, https://blog.mozilla.org/addons/2013/02/28/getpersonas-com-m... and is ongoing)

The themes have been renamed to themes... getpersonas.com is legacy domain that's been unfortunately sticky. It should be resolved in a few weeks: https://blog.mozilla.org/addons/2013/02/28/getpersonas-com-m...


Personas are now just called Themes (background themes, specifically).

One nitpick about the current implementation: It was hard for me to know if I already had a Persona ID. I'm still not sure. I ended up "resetting" my Persona password to log into Trovebox. I have no idea if this actually created my Persona ID by doing so, or if I had one before. A developer like me might realize that this is idempotent and just go ahead, but your ordinary joe user might be put off.

I'm building this into the authentication scheme for my company's new application. It's remarkably easy to get started with. The team did a great job of making it solid and simple.

Persona is nice, because it is simple. It is still important to note that it is an alternative mostly to: "Trust that a user being able to read an email address is proof authenticating said user" -- in other words sites using it have no expectation that the user need any form of authentication before being issued a persona (Similar to eg: shared mail accounts -- where having access to the email does not identify you as a single person/user -- rather as a group of users -- which is subtly different).

Additionally without any form of single sign out/invalidation of private keys/session certificates other than expiration (please correct me if I've missed something wrt sign-out/invalidation) -- persona is in some ways less secure than "trust the mailbox": Even if you change your password/secret key -- any (stolen) signed session certificate (aka token/ticket in most other systems) will remain valid as far as the authorizing site is concerned.

This is similar to a stolen cookie -- except the site cannot decide how long the certificate is valid -- the identity provider does. So if somedomain.net signs certificates valid for a year, the only thing you can do as a site allowing persona logins, is mark said domain as "not trustworthy enough" -- and disallow logins.

This is "fine" as long as Persona isn't used for anything "serious" -- however with social engineering attacks, anything that to the end users appears to be proof of identity can be used to escalate privileges ("He sent me a hipsterchat-message on kewlchat.net -- so I reset the RDP-password like he requested").

I do think moving identity management "closer" to the user is good -- let the ISP, the various organizations the user is identified with vet and administer the user database -- but for the general use case -- we also need some form of trust between the sites, and the iDPs. Shibboleth[1] is one approach to this -- but it is more complicated that Persona, and has more overhead.

Personally I'd like to see a solution based around x509 certs and organizations like https://cacert.org -- but for that to work we need browsers to get better at handling cerificates. That is -- we need a user friendly way to manage identities based around x509 -- and we need browsers and servers to expect to validate both server and client certificates. Unfortunately such validation will entail a lot of problems with expired certs etc... it's not a trivial problem to solve in practice.

[1] http://shibboleth.net/

FYI, latest stable Firefox says this:

You have asked Firefox to connect securely to cacert.org, but we can't confirm that your connection is secure. Normally, when you try to connect securely, sites will present trusted identification to prove that you are going to the right place. However, this site's identity can't be verified.

FYI, latest stable Firefox says...

I'm sure e12e knows this. If you don't want to see that message, you need to install the CAcert root certificate in your browser or OS. While you're doing that, take a look at all the root certificates that are already in there: you might decide CAcert is more trustworthy than most of those organizations!

Indeed. For some painful background, see eg:

A fundamental problem with x509 and Certificate Authorities as it currently stands wrt https and browsers, is that all users almost randomly trust a few organizations to issue certificates -- and get warned of any other certificates -- but there is no decision on part of the user who they trust -- just some vague delegation to browser vendors on vetting CAs.

For some more background, I suggest reading:

edit: Also, I tend to forget that cacert isn't included, as Debian are among the distributions that include them as a CA:


I don't understand how this is an advantage over just using email address as username with a password, like many sites do already. Can someone please explain the benefit?

[Edit: message to user Anonymous09, who replied to me below - you appear to have been hellbanned since the past three weeks. Thought you ought to know.]

Every time you create an account at a new site, you're opening up a way to get hacked. Because, like most humans, you probably reuse passwords, or at least have password similarities. And many web sites tend not to have the resources to properly secure their user database.

So, accounts on every new site you visit is both inconvenient and slowly degrades your security.

You could switch to centralized identity silos, logging in with Facebook or Google everywhere you go. Now you've got the problem that these big companies are tracking your every move, enforcing "real-name" policies forcing you to unify all of your web activity into one account, etc.

Persona is the best of both worlds: convenience and reduced security exposure, plus your choice of identity wherever you go with much better privacy.

Very clear explanation, thanks!

If I knew your email, I could make an account on a website in your name without you knowing.

I don't see how that would cause a problem. If the website ever sent an email to me, I would know about it and just be able to do password recovery and delete the account. If the website never sends an email, it's of no inconvenience to me.

In that case is this not just functionally equivalent to sending a validation email upon account creation, as many sites do already?


If you know his email, then the website's confirmation link will still go to his inbox.

If you know his email and password, then Persona wouldn't help anyway.

> Of course, in the long term, Persona is meant to be distributed: alice@example.com should be verified and certified by the administrators of example.com. If example.com wants to use 2-digit passwords, they can. If they want to use retinal scans powered by your webcam, they can. It’s up to them. With each domain able to customize its authentication protocol with its users, the Web becomes more secure.

How would a 2-digit password make the web more secure?

Let's say I allow users to authenticate into my website with Persona, and I accept alice@example.com--whose 2 digit password is brute-forced the next day. Now whoever got into Alice's account has elevated permissions in my web app too. Great. If I had just stuck with my own authentication scheme at least I could have enforced some minimum complexity.

He was just making a point that authentication protocol is a domain choice (from 2-digit passwords to retinal scan).

It's up to the users to trust the domain he is going to use as identity. Just like many people trust Facebook Connect.

But facebook at least has standards (or is believed to, i have no knowledge).

Why should, for example, google, ever trust, say, fred's discount web hosting, enough to let them login to gmail?

Not in the sense of "these guys could compromise gmail" (which is a worry in certain elevated privileges contexts), but more in the sense that "people are still going to say 'my gmail got hacked'" if their gmail gets hacked because they made bad choices. They do now!

Google will still get blamed, and their only real option is to decide not to accept certain identity providers (IE blacklist or whitelist). Long term, how are we not going to end up with just a mishmash of who accepts what?

I've read a bunch of docs on persona, and it doesn't seem to address this past stating how wonderful user choice is, and how making this more distributed will make the web more secure (which seems, well, wrong)

I think the criticism that we haven't made a strong enough point of why this makes the Web more secure is legitimate. We haven't made this point as well as I'd like.

I'll take that as inspiration for a future blog post. Thanks for pushing us, please continue to do so. We listen.

For most people, they already use an email account to authenticate. Pretty much every single login I have, someone with access to my primary email account could co-opt with the snap of their fingers.

If your email provider is vulnerable, you're already fucked, except for those accounts which use two-factor auth. And persona isn't intended for your bank/etc.

But your argument is essentially "we're just as fucked as we are now". Okay, so then, uh, what problem have we solved?

Now we are fucked, after we're just as fucked but not using facebook as the identity provider?

I guess i don't see this as much of an improvement? Honestly, i'm not trying to be snarky. I'm just trying to understand why this seems to be presented as leaps and bounds above what we have now when it seems to be just as bad, just more distributed :)

No, if you choose a shitty email provider you're fucked. But currenty, you're also fucked on a site by site basis if whoever you have an account stores your password in plaintext/etc.

It's an improvement on having dozens of accounts on dozens of sites, both from a security standpoint and a UX one.

It means users don't have to create and remember a new password for every site they register to, which has security problems.

> Why should, for example, google, ever trust, say, fred's discount web hosting, enough to let them login to gmail?

They're not. They're letting users who use Fred's discount web hosting as their authenticator to log in. Fred's discount web hosting won't even know when their users try to log in to gmail.

Letting someone authenticate that way is no different than allowing passwords than many users reuse all over the net, including on dodgy sites that might very well take that gmail address and password they were handed and see if they can log in to the gmail account with it (want to be on how many users use the same password on their e-mail and other sites they sign up to _using_ that e-mail?), or writing it down all over the place.

> Long term, how are we not going to end up with just a mishmash of who accepts what?

If we do, we're no worse off than we are today.

I hacked together a PhoneGap plugin so you can easily use Persona to log into your mobile apps https://github.com/couchbaselabs/cordova-browserid

I think this is an easier protocol for devs than OpenId or Facebook Connect.

Can anybody explain exactly what is meant by "distributed" here?

Online login services are generally many-to-one. For example, many sites accept Facebook login, but for a user to log in that way, there is only one identity provider they can use: Facebook. If you don't have a Facebook account, or don't want the site in question to have any access to it, you can't use Facebook login.

When the article says "distributed", it means Persona is many-to-many. Any domain can implement the protocol, so when a site accepts Persona login, you can choose from many identity providers – including your own, if you're industrious and want to set one up for your domain. Most people are using Mozilla's service today, but the idea is that email providers like gmail will implement it themselves in the future.

It's used in the sense of "decentralized": no one company controls the Persona system as a whole. Authentication is performed against the domain of the email address the user gives, falling back to authenticating with Mozilla's central server if and only if the domain doesn't support Persona yet.

Pretty sure it means:

It doesn't have to go through Mozilla's servers; anyone can set up their own instance and work with the other ones.

No single authority is needed to vouch for a given identity, instead numerous authorities can validate an identity. That's my understanding.

Distributed identity seems to be notoriously tricky to fully understand for both end-users and developers. I still don't really get OpenID.

I guess they mean that you do not have to use Mozilla servers and can setup your own one (with a retina scan...). I still prefer using theirs as it is less hassle and the same identity can be used across multiple websites.

Not locked to a central service provider.

Is Persona reviving the old Microsoft Passport?

Microsoft first implemented this in early 2000s, I remember Microsoft Passport marketing the single sign-on feature, it did not catch up.


Except that Passport meant using a single authority (Microsoft), whereas Persona is entirely federated (once individual domains opt-in).

I tried to boot the example app eyedee.me and it's unable to find this tarball from the package.json: https://github.com/benadida/node-client-sessions/tarball/92f...

Edit the package.json to point "client-sessions" to:


Sorry, that's my bad. It's fixed now if you pull the latest eyedee.me.

Thanks! I ran into one other issue (PR: https://github.com/mozilla/eyedee.me/pull/27) but was otherwise able to get it booted in our Heroku-esque environment: http://eyedee-me.a.pogoapp.com/

Note: both 2 digits passwords and webcam based retina scans are terribly weak. Always upsets me when sarcasm like this is used, and the author is horribly wrong;-)

How is this different from WebFinger?

And a more detailed question - what is Mozilla's political strategy for getting adoption?

I hope they succeed!

Web technology (http and relatives) was not meant to do this. Can do it? of course, but will do it badly..

Its time to wake up, and see that we need new kinds of technology to keep up evolving

Its like glue wings in a old car and say that it is a plain and can fly..

The idea is good, and we need it badly, but the technology infrastructure its based on is weak for this scenario

Am I the only one to read this as 'Persona is disturbed'?

very cool, looking forward to a more widespread adoption!

It sounds great both for users and for devs which, I'm sure, is going to help it take off.

However I've got one question: was this conceived from the start with security in mind and is it simple enough as to not be plagued with the countless security issues which product that are too complex inevitably run into?

I'm thinking, for example, of the various recent OAuth SNAFUs.

> was this conceived from the start with security in mind

Absolutely. Point 4 in the Mozilla Manifesto: "Individuals' security on the Internet is fundamental and cannot be treated as optional." (http://www.mozilla.org/about/manifesto.en.html#principles)

> is it simple enough as to not be plagued with the countless security issues which product that are too complex inevitably run into?

We hope so. Persona's design and implementation have gone through several internal and external audits, and thus far it appears sound. Keeping everything as simple as possible is a core goal.


building stuff you don't need today

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact