Persona is distributed. Today.
identity.mozilla.com
identity.mozilla.com
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.
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.
No, not really. Because Mozilla is running the Fallback server in the meantime.
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.
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."
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.
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.
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.
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 ?
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.
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.
https://addons.mozilla.org/en-US/firefox/addon/openid-for-fi...
(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.
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.
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.
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.
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.
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)
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 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.
Look for it soon. :)
https://developer.mozilla.org/en-US/docs/Persona/FAQ
You may also wish to take a look at the Mozilla Persona Developer FAQ:
http://www.mozilla.org/en-US/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.
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.
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.'
I mean, look; the OP asked a really good, terse question and got downvoted presumably because it was 'rude.' That's just silly.
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."
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.
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.
It reads like a perfectly reasonable question to me. Where exactly are you finding rudeness and negativity?
Hope it helps a bit.
EDIT: And somebody downvoted this comment. Oh no, I lost 1 HN point! What . will . I . ever . do?
You asked a good question. HN's not very good at self-regulating. Negativity is regarded negatively in some bizarre self-perpetuation cycle.
http://identity.mozilla.com/post/45842909320/users-dont-like...
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).
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.
The point is, nothing prevents the site from knowing me as 70BD6432E50DFB65FF679B32364C3C7840DE4453, but displaying me everywhere as "Aleksey".
Pretty cool it's this straightforward, though.
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."
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.
He's using mobile authenticator as a password mechanism, but it should be modifiable to just trust the local browser.
https://www.rfk.id.au/blog/entry/persona-identity-provider/
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).
Didn't take all that long, I guess. See commit log :)
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:
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?
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.
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.
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.
[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...).
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)
Personas are now just called Themes (background themes, specifically).
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.
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.
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!
https://bugzilla.mozilla.org/show_bug.cgi?id=215243
For some more background, I suggest reading:
http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity/
http://wiki.cacert.org/InclusionStatus[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.]
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.
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.
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.
It's up to the users to trust the domain he is going to use as identity. Just like many people trust Facebook Connect.
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)
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.
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 :)
It's an improvement on having dozens of accounts on dozens of sites, both from a security standpoint and a UX one.
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'll take that as inspiration for a future blog post. Thanks for pushing us, please continue to do so. We listen.
I think this is an easier protocol for devs than OpenId or Facebook Connect.
It doesn't have to go through Mozilla's servers; anyone can set up their own instance and work with the other ones.
Distributed identity seems to be notoriously tricky to fully understand for both end-users and developers. I still don't really get OpenID.
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.
Microsoft first implemented this in early 2000s, I remember Microsoft Passport marketing the single sign-on feature, it did not catch up.
https://github.com/mozilla/node-client-sessions/tarball/92ff...
And a more detailed question - what is Mozilla's political strategy for getting adoption?
I hope they succeed!
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
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.
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