Why Mozilla Persona is the right answer to the question of Identity(labs.newsint.co.uk)
labs.newsint.co.uk
Why Mozilla Persona is the right answer to the question of Identity
http://labs.newsint.co.uk/blog/2012/10/why-mozilla-persona-is-the-right-answer-to-the-question-of-identity/
25 comments
I don't understand why this is better than just using a public/private key to represent identity. Why involve the email operator? Why can't I log in by having my browser sign a certificate, without involving a third party at all?
Because my mother doesn't give two shits about public/private key. She just wants to authenticate and the easiest way both logistically and mentally to do that is to just sign into her email.
I fully support this idea from Mozilla and I hope it kills OpenID, as even that's a pain in the ass sometimes.
I fully support this idea from Mozilla and I hope it kills OpenID, as even that's a pain in the ass sometimes.
Your mom can treat keypair as just another password thing. With the nice exception that she would never have to type it, just click on "sign in as (name)" button and browser/GPG agent combo would do the rest.
I'd note there are tons of solutions involving key escrow, so synchronization and recovery are not problems.
I'd note there are tons of solutions involving key escrow, so synchronization and recovery are not problems.
Surely the real win here is the massive reduction in password re-use on 'less secure' environments.
Obviously google/microsoft etc are not immune to screwing up and having their database hacked - but I'd rather put all my eggs in that basket than having a single egg in lots of baskets with differing levels of security that subsequently enable access to all of my eggs anyway and...
Yeah. So the eggs metaphor doesn't really work. Sorry.
Obviously google/microsoft etc are not immune to screwing up and having their database hacked - but I'd rather put all my eggs in that basket than having a single egg in lots of baskets with differing levels of security that subsequently enable access to all of my eggs anyway and...
Yeah. So the eggs metaphor doesn't really work. Sorry.
My first thought is that completely depends on browser uptake. Persona/BrowserID works whether the browser supports it or not.
Because with browserID your email acts like a public key, and presumably the third party does a better job at securing your private key (with 2 factor auth, biometrics etc) than most people do on their own (the current password theft onslaught proves that). If this gets traction i m sure many hacker groups will come up with independent, noncommercial and nongovernmental authenticators.
We had that, it didn't work.
> Why involve the email operator?
We involved CAs.
> Why involve the email operator?
We involved CAs.
CAs would not be required at all for a simple certificate-signing scheme that could be implemented in a similarly user-friendly way.
How would it work on other people's computers?
The same way it works with Mozilla Persona.
If they're not using their normal browser, they don't have any cert data stored, so they have to 'log in' the traditional way to Mozilla Persona, which then gives the browser the cert data. The whole thing hinges on caching login credentials.
The simplest way to support this without depending on a 3rd party (Mozilla) would be to use an e-mail reset to send you a temporary credential to log in from an "unsafe" computer. There would need to be lots of restrictions on its use of course.
If they're not using their normal browser, they don't have any cert data stored, so they have to 'log in' the traditional way to Mozilla Persona, which then gives the browser the cert data. The whole thing hinges on caching login credentials.
The simplest way to support this without depending on a 3rd party (Mozilla) would be to use an e-mail reset to send you a temporary credential to log in from an "unsafe" computer. There would need to be lots of restrictions on its use of course.
Persona doesn't involve any hard dependency on Mozilla. The user can use another ID provider (or even run their own) and the site can verify the credentials without using Mozilla's webservice. Both are currently unlikely, but it's easy to imagine GMail being an ID provider in the future.
can i supply more than one so sites could check if one of the providers has been compromised or something similar? does it make sense to have more than one?
As I understand it, it checks with the domain from the 'email address' to verify you. (air quotes because it needn't be possible to send email to the identifier). So it wouldn't make sense to have more than one way to verify one ID. If the site you're signing into is particularly sensitive, it could require a separate check - perhaps even a second BrowserID login from a different domain.
Okay, replace my usage of 'Mozilla' with 'ID provider'. The point is we can do all of this without an 'ID provider' today.
E-mailing temporary credentials still effectively relies on an ID provider: your mail server, which must ensure that no-one else can read e-mail sent to your address. You can run both that and a BrowserID provider yourself if you don't trust someone else to do it.
BrowserID is much easier for the web developer to set up and for the user to log in with: no switching between tabs to copy and paste passwords from your e-mail.
BrowserID is much easier for the web developer to set up and for the user to log in with: no switching between tabs to copy and paste passwords from your e-mail.
I think part of it is that sites want email addresses for their users.
Making the email address part of the protocol lowers the bar for sites to join the ecosystem.
Making the email address part of the protocol lowers the bar for sites to join the ecosystem.
Good question. This was actually implemented in Firefox a while ago, I even remember actually finding it in use in the wild once. The key issue there is how do users manage their certificates? Their 'passwords' are now a set of certificates stored somewhere. These certs need to be accessible from their phone, their work computer, their home computer, the cyber cafe, their friend's computer, and so on.
I see two possible solutions to this. One is storing these certs in the cloud, the other is hard token like a flash drive. The problem with the physical token is that it can be lost, so it needs to be backed up somewhere. Where to back it up? The cloud seems the natural answer. How do you reliably authenticate this cloud cert storage system in a way that a person can't just lose or forget? And we're back to email.
Persona reduces all of these things down to the email account. Assuming they did it right (I haven't gone into the details yet) then they're introducing no new attack vectors (someone with your email can own most of your accounts already) and they're eliminating the password from most places. Seems like a win to me.
I see two possible solutions to this. One is storing these certs in the cloud, the other is hard token like a flash drive. The problem with the physical token is that it can be lost, so it needs to be backed up somewhere. Where to back it up? The cloud seems the natural answer. How do you reliably authenticate this cloud cert storage system in a way that a person can't just lose or forget? And we're back to email.
Persona reduces all of these things down to the email account. Assuming they did it right (I haven't gone into the details yet) then they're introducing no new attack vectors (someone with your email can own most of your accounts already) and they're eliminating the password from most places. Seems like a win to me.
So, we have two options:
1. Tie identity to email address. No means of backup (you just can't back up your email provider), no sensible migration possibilities, system is as vulnerable as your email account.
2. Tie identity to keypair. Let email provider (or other trusted third party) sign it, validating the email address. Then escrow the pair and allow recovery by passphrase and email validation, and/or put it on hardware token, and/or hide a piece of paper in a safe behind a cupboard. Simple means of migration (just authenticate with old key and new address), huge flexibility of choices between security and usability.
Both options may have the same default UI/UX and they share very similar workflow. Generate keypair, let the provider perform the email validation, get the signature, give it to the consumer. The only difference is what's finally tied to your account — your address or your public key.
1. Tie identity to email address. No means of backup (you just can't back up your email provider), no sensible migration possibilities, system is as vulnerable as your email account.
2. Tie identity to keypair. Let email provider (or other trusted third party) sign it, validating the email address. Then escrow the pair and allow recovery by passphrase and email validation, and/or put it on hardware token, and/or hide a piece of paper in a safe behind a cupboard. Simple means of migration (just authenticate with old key and new address), huge flexibility of choices between security and usability.
Both options may have the same default UI/UX and they share very similar workflow. Generate keypair, let the provider perform the email validation, get the signature, give it to the consumer. The only difference is what's finally tied to your account — your address or your public key.
Argh. Why am I so late to this thread?
This is possible. Your BrowserID provider can do public/private key auth. You could have an identity that is provided for (you could do this yourself on your own domain) that you authenticate to via a private key.
That's how flexible this protocol is. The provider has a huge range of discretion about how the account is authenticated.
This is possible. Your BrowserID provider can do public/private key auth. You could have an identity that is provided for (you could do this yourself on your own domain) that you authenticate to via a private key.
That's how flexible this protocol is. The provider has a huge range of discretion about how the account is authenticated.
The problem is, one can't own a domain, but only lease it for a time being. And one can't migrate between [email protected] and [email protected].
That's how inflexible this protocol is, compared with a simple keypair.
That's how inflexible this protocol is, compared with a simple keypair.
This Persona/BrowserID kludge makes me sick. I don't get why everyone is so optimistic about it. I believe there's absolutely no reason why one just can't be a source of their own identity (as it naturally happens), with so-called "identity providers" actually being "identity notaries."
In BrowserID they do generate keypair, but then tie identity not to it, but to an email address, something user lends, but never actually possesses. Completely the same as with OpenID, where identity is tied to URI. Actually, the only change is URI scheme part: http/https to mailto — which is nice UX-wise, but that's about all the advantages.
OpenID was heavily criticized for that (remember all those "did I sign up with Google or Facebook?", URI changes/account rename issues, identity providers being temporarily down, and so on?), and now those who criticized OpenID are praising system that have most of the same problems.
I can only hope Persona would silently fail and never gain any significant popularity, so users won't have to struggle with another hype wave, to only lose their trust (if there's any left) in non-centralized identity systems.
In BrowserID they do generate keypair, but then tie identity not to it, but to an email address, something user lends, but never actually possesses. Completely the same as with OpenID, where identity is tied to URI. Actually, the only change is URI scheme part: http/https to mailto — which is nice UX-wise, but that's about all the advantages.
OpenID was heavily criticized for that (remember all those "did I sign up with Google or Facebook?", URI changes/account rename issues, identity providers being temporarily down, and so on?), and now those who criticized OpenID are praising system that have most of the same problems.
I can only hope Persona would silently fail and never gain any significant popularity, so users won't have to struggle with another hype wave, to only lose their trust (if there's any left) in non-centralized identity systems.
As good as it may be, I have a hard time seeing this grow beyond Mozilla browsers, what with their reliance on browserid
Works in any modern browser. Check this out:
https://developer.mozilla.org/en-US/docs/persona/Browser_com...
Try it today on your iPhone, iPad, or stock Android browser. This is a cross-device, cross-browser solution.
That's what the Javascript shim is for.
This just beats OpenID hands down. And I will be very interested to see how fast Google et al support it.
I think they may be a bit evil.
I think they may be a bit evil.
I don't see a compelling reason, especially since I'm in the EU and don't want my e-mail address, password and website usage statistics transferred to Mozilla's servers in the US, where they can be accessed and possibly misused by authorities.
Mozilla has the only implementation at the moment as they are still developing it, but the intention is that any email provider can provide this in the future. They have not written themselves into the spec. In fact they have commented that the more successful this standard is, the less important they become.
Commendable goals, but in my opinion somewhat conflicts with the 'Mozilla' prefix in the name, if they hope to make it a widely adopted standard they need to drop their branding and just call it 'Persona'.
Read the article. The protocol is called BrowserID. The Mozilla service to try and help adoption is called "Mozilla Persona"
> don't want my e-mail address, password and website usage statistics transferred to Mozilla's servers in the US
Isn't the whole point of Persona that... it's not? Or it doesn't have to at least? In fact, two of the main motivations of Persona are 1. decentralized identity provider (so you don't have to rely on Mozilla) and 2. that the identity provider should not know which websites you're using (so whoever you're relying on doesn't have to know you're looking at cat pictures)
Isn't the whole point of Persona that... it's not? Or it doesn't have to at least? In fact, two of the main motivations of Persona are 1. decentralized identity provider (so you don't have to rely on Mozilla) and 2. that the identity provider should not know which websites you're using (so whoever you're relying on doesn't have to know you're looking at cat pictures)
None of these have to go through Mozilla if you don't want them to. You can host your own copy of the JavaScript shim and setup your own identity provider to authenticate against and it will Just Work.
There'll be no time before you'll see european based identity provider. my company is looking into it at the moment and we are sure we are not alone.
I'm genuinely curious. I did my bachelor's thesis on the identity ecosystem. I was an early adopter of CardSpace, iNames, OpenID, and any other digital identity solution that came along and I watched them wither from lack of interest. I was continually told that passwords are good enough, and that nobody is interested in a digital identity solution.
Persona doesn't sound that different from solutions that came before it. It sounds really similar to CardSpace, especially with how easily you can integrate it into a site. So why would Persona have a chance at succeeding where so many others have failed? Is it just a matter of timing, coming after some major password leaks, or are they hoping the Mozilla name will buy them support from the developer community?
Persona doesn't sound that different from solutions that came before it. It sounds really similar to CardSpace, especially with how easily you can integrate it into a site. So why would Persona have a chance at succeeding where so many others have failed? Is it just a matter of timing, coming after some major password leaks, or are they hoping the Mozilla name will buy them support from the developer community?
I'd say a key innovation of Mozilla Persona is the marketing. It's got the Mozilla brand on it, it's well explained, the demos are slick. That may seem like fluff but it may make a significant difference in adoption. (See also: Stripe.)
I am not familiar with CardSpaces, but a considerable difference between OpenID and Persona is a matter of anonymity. With OpenID, your OpenID provider (e.g. Google) can track you as you log to your various accounts. By opposition, with Persona, the Persona provider does not get any meaningful information that can be used to blow your anonymity.
tl;dr - Here's a video demonstration: http://youtu.be/0_6rC025sK0?t=34m16s
CardSpace was a Microsoft project led by Kim Cameron, the godfather of digital identity. They originally wanted to make it part of Windows Vista, but it was dropped for lack of interest. It was an open standard, and there were browser plugins to make it work in other browsers and operating systems. Microsoft knew they couldn't make it a Windows-only thing if they wanted people adopting it. They just wanted to be at the forefront of security for once.
A developer would add meta tags to a site's login page with a URL to post identity info to and a list of information it's requesting. That would trigger the browser (or plugin) to open a modal display of identity "cards", which the user could choose from. Then it would show what information the site requested and they could deny individual pieces of info. The data would be posted back to the site, along with a unique signature for that user & site.
Cards could be self-issued or issued by a third party, like your employer or bank. They could have graphical backgrounds applied so they looked more like ID cards or credit cards. It was a great UI for identity, and easy for developers to use. But I think the Microsoft name tarnished it. I know people outside the identity community were making comments about how this was Microsoft's attempt to become Big Brother & so forth, even though Microsoft was completely out of the communication loop between the user and the site.
CardSpace was a Microsoft project led by Kim Cameron, the godfather of digital identity. They originally wanted to make it part of Windows Vista, but it was dropped for lack of interest. It was an open standard, and there were browser plugins to make it work in other browsers and operating systems. Microsoft knew they couldn't make it a Windows-only thing if they wanted people adopting it. They just wanted to be at the forefront of security for once.
A developer would add meta tags to a site's login page with a URL to post identity info to and a list of information it's requesting. That would trigger the browser (or plugin) to open a modal display of identity "cards", which the user could choose from. Then it would show what information the site requested and they could deny individual pieces of info. The data would be posted back to the site, along with a unique signature for that user & site.
Cards could be self-issued or issued by a third party, like your employer or bank. They could have graphical backgrounds applied so they looked more like ID cards or credit cards. It was a great UI for identity, and easy for developers to use. But I think the Microsoft name tarnished it. I know people outside the identity community were making comments about how this was Microsoft's attempt to become Big Brother & so forth, even though Microsoft was completely out of the communication loop between the user and the site.
Sounds interesting, but I never heard of it. This is a common issue for big corps - they see good ideas as not being popular enough, so they don't market them. Self-fulfilling prophecy.
I tried logging in to OpenPhoto with my Gmail address, and there's my profile photo pulled from my Google account. How can I be sure no tracks were created in the process of getting that image?
Once the site you sign into has your identity, the protocol can't stop them announcing to the world that you have signed in. But it doesn't require the ID provider to know where you're signing in.
Also, are you sure it's not from gravatar? In my case, it's the same image as the google profile photo.
Also, are you sure it's not from gravatar? In my case, it's the same image as the google profile photo.
My Gmail and Gravatar are different, and it definitely didn't pull the one from Gmail. I use that image on other sites, but not on GMail.
So I think it's very likely that it's just Gravatar, and all you need is an email address to pull that.
So I think it's very likely that it's just Gravatar, and all you need is an email address to pull that.
I didn't remember setting up a Gravatar for my Gmail address, but it turns out I did, so yes, it's entirely possible it's from Gravatar. I feel better about that, although I guess Gravatar can track me now.
If you log into a service, that service can inform arbitrary third parties that you've logged in. By requesting your photo from google it is doing so, but how would you stop this at the protocol level?
To be honest it "feels" like the right time.
But i have to say unless Google/Yahoo/Facebook/Twitter support this it will whitehr and die. I suppose it depends if they are really watching what we login to with openid.
But i have to say unless Google/Yahoo/Facebook/Twitter support this it will whitehr and die. I suppose it depends if they are really watching what we login to with openid.
> But i have to say unless Google/Yahoo/Facebook/Twitter support this it will whitehr and die.
Why? It might not become ubiquitous if they big players don't support it, but it could become the alternative that all the other sites use and makes their lives easier.
I don't see a network effect here that means only one method will win and all the others lose.
Why? It might not become ubiquitous if they big players don't support it, but it could become the alternative that all the other sites use and makes their lives easier.
I don't see a network effect here that means only one method will win and all the others lose.
I wonder how feasible it would be to shim OpenID and OAuth on top of this? Many major email providers offer OpenID or OAuth to verify email ownership. If the browser fell back to using one of those, it wouldn't need to use the alternate user/pass system in Persona.
The Persona team is actively working on this, actually. When a domain can't certify its own users, we fall back to having login.persona.org act as a third-party verifier. Of course, login.persona.org needs proof that you are who you say you are, so on first contact we create a password and do a standard email confirmation. Semantically, we'd get the same assurance, and better UX, by bridging to OpenID (Yahoo, Google) and OAuth (Hotmail). So we're doing that. :) This is a major Q4 goal for us, and we're mostly code-complete, modulo things that turn up in QA.
if I understand you correctly, That rather defeats the privacy defending part of persona. At the moment any site who wants to verify me through openid has to request back to gmail. So google knows every time I log into a openid site, which site it is, and can also refuse to verify me if they choose (not in enough circles, arrived at site with a bing.com referrer header etc etc)
no, I like this design, and I am guessing the reason only time crossword signed up is that google and yahoo like knowing which sites I have visited. Making me even more happy to move away
no, I like this design, and I am guessing the reason only time crossword signed up is that google and yahoo like knowing which sites I have visited. Making me even more happy to move away
I would love to use this, but apps I work on are both web browser based and native clients. Persona does not yet work with native apps (Android, iOS native apps); it only supports browser based auth right now.
Browser only auth doesn't get me all the way there. I can look at wrapping UIWebKit, or whatever, in my apps, but I bet I am just asking for some hurt. :-)
Browser only auth doesn't get me all the way there. I can look at wrapping UIWebKit, or whatever, in my apps, but I bet I am just asking for some hurt. :-)
[deleted]
The recent wave of password and hash theft might become an incentive to move to this login method. I was skeptic about the possibility of BrowserID catching on, thinking the Google/Twitter/FB wouldn't give up tracking users with their ID methods. But if there is a way to make this widespread (though I can't imagine how) I'd really like it to happen.
Will Mozilla provide native support or an extension? Or they feel like it would hurt if someone could implement a bad login page that still works if the browser has native support?
Will Mozilla provide native support or an extension? Or they feel like it would hurt if someone could implement a bad login page that still works if the browser has native support?
Password/hash thefts have been happening for as long as there have been systems with passwords. What changed recently is that we now have centralized services with huge numbers of important accounts. There are more service with large number of accounts and more services that affect multiple aspects of your digital life. When someone steals hashes from those, the press and people are more likely to notice.
I think most people overemphasize the importance of the particular authentication scheme used and overlook the problems created by extreme centralization of stuff.
I think most people overemphasize the importance of the particular authentication scheme used and overlook the problems created by extreme centralization of stuff.
> Will Mozilla provide native support or an extension?
They have a working native support - http://www.soeren-hentzschel.at/mozilla/persona/2011/07/15/m... - and expect it to see it natively in probably ~17. Their biggest push is for WebKit to adopt a similar solution based off the same tech.
They have a working native support - http://www.soeren-hentzschel.at/mozilla/persona/2011/07/15/m... - and expect it to see it natively in probably ~17. Their biggest push is for WebKit to adopt a similar solution based off the same tech.
The biggest problem with Mozilla's Persona is the branding of it. Until they are able to get a handle on the branding-related issues, it can't get off the ground:
* Logo is ambiguous and looks like a generic button
* "Mozilla" in the name instantly steers away other browsers
We've implemented it on LinkUp (https://www.linkup.com/account/), love the technology, and REALLY hope the adoption of it takes off - but until I can explain it to a user in 2 sentences, it won't claim the throne.
* Logo is ambiguous and looks like a generic button
* "Mozilla" in the name instantly steers away other browsers
We've implemented it on LinkUp (https://www.linkup.com/account/), love the technology, and REALLY hope the adoption of it takes off - but until I can explain it to a user in 2 sentences, it won't claim the throne.
You are so right. I implemented browserid when it was named "BrowserID" and it really made better sense (the name was pretty self explanatory). "Mozilla persona" sounds like something that only some obscure subcult of firefox users should use.
I would urge mozilla to remove all branding from the popup. It's gonna get really confusing when 3rd party popups get into the game (would they call it Google browserID or "google's version of persona"?). Second, since websites are not getting any private information from mozilla, mozilla is barely relevant. Third, while mozilla's work is commendable, users don't need a link to learn about the protocol and that it's benevolently "built by a nonprofit", instead they trust that the target website knows what it's doing by showing that popup.
I would urge mozilla to remove all branding from the popup. It's gonna get really confusing when 3rd party popups get into the game (would they call it Google browserID or "google's version of persona"?). Second, since websites are not getting any private information from mozilla, mozilla is barely relevant. Third, while mozilla's work is commendable, users don't need a link to learn about the protocol and that it's benevolently "built by a nonprofit", instead they trust that the target website knows what it's doing by showing that popup.
98% in agreement.
I think the "built by a nonprofit" is a fantastic point that they should keep pushing, though.
I think the "built by a nonprofit" is a fantastic point that they should keep pushing, though.
To pile on, I thought 'persona' was an addon by which I could make firefox look different.
Exactly what comes to my mind. "[…] easy-to-use themes that let you personalize the look of your Firefox."[1]
[1] http://www.getpersonas.com
[1] http://www.getpersonas.com
There is a really easy way to explain Persona to users:
"Sign in with your email address"
At Voost (https://www.voo.st/) we have been using BrowserID since launch earlier this year. We just use this simple phrase and users "get it" right away. There's no need for complicated branding.
"Sign in with your email address"
At Voost (https://www.voo.st/) we have been using BrowserID since launch earlier this year. We just use this simple phrase and users "get it" right away. There's no need for complicated branding.
Except this would only work if you:
1) Forced all users in your system, who already had email/password based accounts, to abandon their existing accounts and adopt Persona
2) Became fluent in quickly explaining to users how to reset their Persona password when they forget it
3) Don't mind losing all the users who say "I trust you, but not this company I haven't heard of before." Some users, especially jobseekers, won't let their circle of trust grow - and forcing adoption of a 3rd party causes abandonment. But so does a complicated sign-in process, so you just need to figure out if group A or group B is larger because you can't make everyone happy.
1) Forced all users in your system, who already had email/password based accounts, to abandon their existing accounts and adopt Persona
2) Became fluent in quickly explaining to users how to reset their Persona password when they forget it
3) Don't mind losing all the users who say "I trust you, but not this company I haven't heard of before." Some users, especially jobseekers, won't let their circle of trust grow - and forcing adoption of a 3rd party causes abandonment. But so does a complicated sign-in process, so you just need to figure out if group A or group B is larger because you can't make everyone happy.
#1 makes no sense. If you already have email-based accounts, switching to Persona is trivial - you just switch to Persona auth and everything works as-is with email as the account key. You will of course want to give users a little warning, but the process is far simpler than almost any other change you can make to your authentication system (eg, deconfliciting usernames). The only real change when switching to Persona is that you drop your stored password. It's still "sign in with your email address".
#2 has not been a problem, as far as we can tell. If users forget their passwords, the reset-password process on the Persona login dialog works great - better than almost every other password-based website I've used. In the long run, passwords are only maintained by primary IdPs like Gmail, so this is even less of an issue.
#3 is totally dependent upon your audience. We definitely get pushback on Facebook auth - you can't run a FB-only login system without alienating a significant chunk of most audiences. Initially we tried to encourage FB auth by making BrowserID less obvious, but that just produced a lot of angry emails from people who didn't realize they had an alternative. Now that Persona and FB auth are on equal footings, we have yet to have anyone complain about the signup process. YMMV.
#2 has not been a problem, as far as we can tell. If users forget their passwords, the reset-password process on the Persona login dialog works great - better than almost every other password-based website I've used. In the long run, passwords are only maintained by primary IdPs like Gmail, so this is even less of an issue.
#3 is totally dependent upon your audience. We definitely get pushback on Facebook auth - you can't run a FB-only login system without alienating a significant chunk of most audiences. Initially we tried to encourage FB auth by making BrowserID less obvious, but that just produced a lot of angry emails from people who didn't realize they had an alternative. Now that Persona and FB auth are on equal footings, we have yet to have anyone complain about the signup process. YMMV.
Which email address?
And what (else) will I be signed into?
If Chrome and Google+ support Persona, they would validate the system and get an advantage on Facebook.
Facebook blew it. They could have been identity for the internet, but with all the privacy and spam problems users HATE logging in with Facebook connect. We tried it for a website and it just failed. There's huge resistance.
Facebook blew it. They could have been identity for the internet, but with all the privacy and spam problems users HATE logging in with Facebook connect. We tried it for a website and it just failed. There's huge resistance.
I just tried to login into your site without being registered with Persona. All works fine, I can choose a password, and receive an email with confirmation link. When I click it I see an info box from Persona, but after only 3 seconds or so I get redirected to your site - so that is buggy. I see then a notice that your site couldn't log me in, which is fine, as I don't have an account. However, your site then starts to log me in over and over again. Which seems an issue on your site. Hope this info helps. I'm using chrome on OS X.
Thank you so much for the thorough details. I squashed this bug. Can you ping me at [email protected] so I can send you a Starbucks giftcard for your help?
> We've implemented it on LinkUp (https://www.linkup.com/account/)
What's your experience with that? Implementing OpenID tends to not be very fun (whether as a consumer or as a provider), is Persona better?
What's your experience with that? Implementing OpenID tends to not be very fun (whether as a consumer or as a provider), is Persona better?
I did OpenID early on in the site (nobody understood it), RPXNow/JanRain (more than we could afford for fewer features than we needed), and finally our own solution that does OAuth* for the various providers and Persona.
I love Persona. I want a Persona shirt and tattoo. OpenID was just a bit harder, but had nowhere near the payout that using Persona offers. The only burden of Persona is the auto-login/logout handling, which is a good thing in the long-run but in the short-run involves tracking down all your login/logout methods and making sure they all react properly.
*OAuth integration is a nasty mess of nastiness that I can't bring up w/o derailing this entire conversation. If you want to chat about that train-wreck, email me.
I love Persona. I want a Persona shirt and tattoo. OpenID was just a bit harder, but had nowhere near the payout that using Persona offers. The only burden of Persona is the auto-login/logout handling, which is a good thing in the long-run but in the short-run involves tracking down all your login/logout methods and making sure they all react properly.
*OAuth integration is a nasty mess of nastiness that I can't bring up w/o derailing this entire conversation. If you want to chat about that train-wreck, email me.
I also adore Persona. It took me two minutes to integrate on my Django setups the first time, and less than that on subsequent ones. Nowadays, it's all I use.
Not the GP, but I was thrilled with how easy it is to integrate. I have a little site that I'm putting together as a hobby, and it took me about an afternoon. Web development isn't my specialty, so if you know what you're doing you could probably do it in less than an hour.
Those expanding buttons on hover are terrible. a) hover is useless on a touch screen device. b) it feels like a moving target.
I'm curious how you deal with someone logging in with one system and then coming back and logging in with another. Do you have a way to merge accounts somehow?
Also, I clicked on yahoo and got this: http://www.evernote.com/shard/s178/sh/faba70e1-03e6-4448-81f...
I'm curious how you deal with someone logging in with one system and then coming back and logging in with another. Do you have a way to merge accounts somehow?
Also, I clicked on yahoo and got this: http://www.evernote.com/shard/s178/sh/faba70e1-03e6-4448-81f...
Thanks for the feedback. We're still working on nailing the design - we need a way that all the buttons look uniform, and want a way to explain what they are (namely Persona, as I said, still working on it.) And fitting the multiple options in the small space is no easy feat. Fortunately hover isn't necessary for interaction, so the touch screen device point is moot. And the "moving target" is the same reaction as people gave Apple's dock. But you're right - this design isn't perfect yet.
Once a user's source authenticity is verified, we give the option to merge accounts once we detect overlaps. So if you login via Twitter, verify your Yahoo! email address through the profile, and then login through Yahoo!, you'll be in the same account as you were in the 1st login. We have ~20 scenarios that we maintain for logins, and have heard 0 complaints on the assumptions we have in practice.
Thanks for the screenshot - we'll get that fixed today. Would you like an email once it is resolved?
Once a user's source authenticity is verified, we give the option to merge accounts once we detect overlaps. So if you login via Twitter, verify your Yahoo! email address through the profile, and then login through Yahoo!, you'll be in the same account as you were in the 1st login. We have ~20 scenarios that we maintain for logins, and have heard 0 complaints on the assumptions we have in practice.
Thanks for the screenshot - we'll get that fixed today. Would you like an email once it is resolved?
[deleted](1)
Yahoo! login bug has been fixed.
Teaches me to try and get Yahoo! to behave with https. If anyone wants a great example of why to use Persona, try using Yahoo's developer apps interface...
Teaches me to try and get Yahoo! to behave with https. If anyone wants a great example of why to use Persona, try using Yahoo's developer apps interface...
I like the implementation but I don't like that it has a brand (Mozilla) attached to it.
Stripe is doing this right, when you make a payment on a website you have no idea that you're using Stripe.
Stripe is doing this right, when you make a payment on a website you have no idea that you're using Stripe.
I won't put credit card details into a site unless I have some trust in the system they're using. The lack of a brand isn't necessarily a good thing here.
In any case, the brand is for marketing to developers right now -- once "Persona" becomes a thing in and of itself, this will be a nonissue.
In any case, the brand is for marketing to developers right now -- once "Persona" becomes a thing in and of itself, this will be a nonissue.
tl;dr Uses an e-mail address to make public key crypto easier. Sounds nice.
Unfortunately, most people fuck up PKI and now we're relying on a third party (Mozilla) to authenticate all our logins.
You could also just implement client certificates without a third party. Issue your users a cert when they register or log in. This would be similarly "automatic" authentication without relying on Persona to be stable and secure 24/7. I wonder why they didn't just make a browser plug-in that simplifies using client certificates (without the expense of supporting a highly reliable 3rd-party site and extra code to make it work)
Unfortunately, most people fuck up PKI and now we're relying on a third party (Mozilla) to authenticate all our logins.
You could also just implement client certificates without a third party. Issue your users a cert when they register or log in. This would be similarly "automatic" authentication without relying on Persona to be stable and secure 24/7. I wonder why they didn't just make a browser plug-in that simplifies using client certificates (without the expense of supporting a highly reliable 3rd-party site and extra code to make it work)
I wonder why they didn't just make a browser plug-in that simplifies using client certificates (without the expense of supporting a highly reliable 3rd-party site and extra code to make it work.
So the goal is basically: I have a computer at work, a computer at home, a computer in my pocket, and a computer I just borrowed to check something at a friend's house. I want to be able to go to the same random site on all four devices and have it recognize that I am the same person, without (1) remembering a special password for that site, or (2) trusting that site in any way.
So there are two ways to do that. One involves generating a certificate on one of my devices and somehow communicating it to the others without a central authority. The other involves a central authority that each device can communicate with.
The first way will be, let's say, extremely challenging to get working reliably across all devices and platforms in a way that average users can handle. So Mozilla went with an extremely flexible version of the second way. It goes like this: users remember a Username and URL, in the form Username@URL. They also remember a Password which is only shared with URL. When I want to identify myself to that random website on any of my four devices, Mozilla helps me get a verifiable statement from URL to send to the random website that I am Username@URL.
There are two things mixed in to make it more likely this will take off. First, users are already used to remembering Username@Url / Password credentials, so they don't have to learn anything new to identify this way. And second, because existing Username@Url identities are email addresses, Mozilla can offer an intermediate identification service based on the ability to receive email, until other identity servers come online.
TL;DR: By using an intermediate ID server and credentials that look like email addresses, Mozilla has created a path to cross-device, cross-platform user ID that solves the problems of user adoption, technical adoption, and independence -- it can be implemented in existing browsers, understood by existing users, and offers a clean transition to completely decentralized identification. Very cool.
So the goal is basically: I have a computer at work, a computer at home, a computer in my pocket, and a computer I just borrowed to check something at a friend's house. I want to be able to go to the same random site on all four devices and have it recognize that I am the same person, without (1) remembering a special password for that site, or (2) trusting that site in any way.
So there are two ways to do that. One involves generating a certificate on one of my devices and somehow communicating it to the others without a central authority. The other involves a central authority that each device can communicate with.
The first way will be, let's say, extremely challenging to get working reliably across all devices and platforms in a way that average users can handle. So Mozilla went with an extremely flexible version of the second way. It goes like this: users remember a Username and URL, in the form Username@URL. They also remember a Password which is only shared with URL. When I want to identify myself to that random website on any of my four devices, Mozilla helps me get a verifiable statement from URL to send to the random website that I am Username@URL.
There are two things mixed in to make it more likely this will take off. First, users are already used to remembering Username@Url / Password credentials, so they don't have to learn anything new to identify this way. And second, because existing Username@Url identities are email addresses, Mozilla can offer an intermediate identification service based on the ability to receive email, until other identity servers come online.
TL;DR: By using an intermediate ID server and credentials that look like email addresses, Mozilla has created a path to cross-device, cross-platform user ID that solves the problems of user adoption, technical adoption, and independence -- it can be implemented in existing browsers, understood by existing users, and offers a clean transition to completely decentralized identification. Very cool.
This makes it easier for people to use one login for all the websites they use. That also makes them inherently less secure.
Multiple accounts is a good idea because it creates separate security domains which cannot be broken. You crack my Facebook password, there's no way you can get into my completely separate Citibank account. The one-login-for-all model is less secure because it centralizes your accounts into one general security domain: the ID provider.
If you hadn't made it a requirement that you can use the computer at your friend's house, this would be more secure, because you could keep your private keys just on your trusted devices. But now you're on a foreign device and you didn't bring your keys - so you have to either get them from your ID provider, or generate new ones.
Now an attacker can either A. break into the ID provider and steal the keys for all the sites you use, or B. intercept the username/password login to your ID provider.
The risk of A. is of course possible, plausible, and given the track record of companies with the highest security reputations in the land being pwnd by lame phishing expeditions, likely to actually work (eventually).
If you were using your home computer with the keys already stored in the browser, B. would be impossible, but you're at a friend's house with no keys. And my guess is there will be malware developed just to disable browser keys, force a u/p login, collect the creds, and try all online banks using this system to find your account and siphon funds. (This is exactly what malware does today, only they usually use direct injection of your normal banking browser sessions or steal saved logins)
Of course you can use separate accounts with Persona. They advertise you using a work e-mail and personal e-mail to make separate accounts. But let's be realistic: who the hell wants to complicate their logins further? People will probably use one e-mail for all their accounts - because it's easy.
I have a solution for these security concerns. It's to stop trying to making security easy. If you forced people instead to jump through hoops for the one or two accounts which really need to be extra secure, they'll deal with it (once) and get on with their lives.
Banking is one example. You can step a user through generating and storing a client certificate, and then they never have to do it again until they use a new computer. If they need access from outside their home (WHICH IS A BAD IDEA, BUT ANYWAY,) they can use a temporary e-mailed login token which is only good for one session and requires things like login rate limits, additional identity verification, etc. We can do this today without any new technology.
Facebook, Twitter, etc aren't sensitive accounts and thus don't need ridiculous security - Persona would be fine for these. Crack my social media accounts, fine, but don't allow things like banks and e-mail accounts to be linked as well. It's like clipping blank checks to your house or office keys.
Multiple accounts is a good idea because it creates separate security domains which cannot be broken. You crack my Facebook password, there's no way you can get into my completely separate Citibank account. The one-login-for-all model is less secure because it centralizes your accounts into one general security domain: the ID provider.
If you hadn't made it a requirement that you can use the computer at your friend's house, this would be more secure, because you could keep your private keys just on your trusted devices. But now you're on a foreign device and you didn't bring your keys - so you have to either get them from your ID provider, or generate new ones.
Now an attacker can either A. break into the ID provider and steal the keys for all the sites you use, or B. intercept the username/password login to your ID provider.
The risk of A. is of course possible, plausible, and given the track record of companies with the highest security reputations in the land being pwnd by lame phishing expeditions, likely to actually work (eventually).
If you were using your home computer with the keys already stored in the browser, B. would be impossible, but you're at a friend's house with no keys. And my guess is there will be malware developed just to disable browser keys, force a u/p login, collect the creds, and try all online banks using this system to find your account and siphon funds. (This is exactly what malware does today, only they usually use direct injection of your normal banking browser sessions or steal saved logins)
Of course you can use separate accounts with Persona. They advertise you using a work e-mail and personal e-mail to make separate accounts. But let's be realistic: who the hell wants to complicate their logins further? People will probably use one e-mail for all their accounts - because it's easy.
I have a solution for these security concerns. It's to stop trying to making security easy. If you forced people instead to jump through hoops for the one or two accounts which really need to be extra secure, they'll deal with it (once) and get on with their lives.
Banking is one example. You can step a user through generating and storing a client certificate, and then they never have to do it again until they use a new computer. If they need access from outside their home (WHICH IS A BAD IDEA, BUT ANYWAY,) they can use a temporary e-mailed login token which is only good for one session and requires things like login rate limits, additional identity verification, etc. We can do this today without any new technology.
Facebook, Twitter, etc aren't sensitive accounts and thus don't need ridiculous security - Persona would be fine for these. Crack my social media accounts, fine, but don't allow things like banks and e-mail accounts to be linked as well. It's like clipping blank checks to your house or office keys.
Persona is seriously decentralized. If your email provider has native support, and your browser has native support, then you're completely free from any dependance on Mozilla-hosted services, automatically. Assertions can be validated completely locally, without ever involving Mozilla in the transaction.
If you don't want to trust Mozilla, you don't have to.
If you don't want to trust Mozilla, you don't have to.
Have any of the other major browsers made any public statements about BrowserID or Persona? How about Paul Irish or other developer relations type people? Somebody has to have said something even if it was 'unofficial'.
Persona - An identity system by Mozilla
Personas - Skins for the Firefox Web Browser
This is an issue that needs to be resolved.
Personas - Skins for the Firefox Web Browser
This is an issue that needs to be resolved.
They've resolved it in planning (http://www.ghacks.net/2012/03/02/mozilla-personas-renamed-to...), but the implementation just hasn't been completed. Yet.
"To sum it up:
* BrowserID renamed to Mozilla Persona
* Personas renamed to Background Themes
* Themes are now Complete Themes"
"To sum it up:
* BrowserID renamed to Mozilla Persona
* Personas renamed to Background Themes
* Themes are now Complete Themes"
Background Themes/Complete Themes - sounds like they just created a new problem. Throwing the word 'theme' in there for backgrounds is just asking for confusion.
I think most people understand Wallpapers (Backgrounds) / Themes.
I think most people understand Wallpapers (Backgrounds) / Themes.
I get that I'm probably not the target market for OpenID since I'm already more tech-friendly than the average user, but I've never thought it was super complicated or "jarring," to use the definition in the article. I set up the URL on my web server years ago (thus securing me as more technical, I know), but it's been great. I can change providers in the background, and I only need to remember one URL. No more usernames or anything. Sure, it could be easier and more widely adopted (chicken and egg), but I have thought it was relatively pleasant for a while.
I personally like OpenID, especially in combination with GMail. But if this is easier for most users (and it seems to be) then I could be fan of it as well.
One thing that I don't see is what happens if I sign up as a user now (with my GMail address) and then GMail later starts providing their own service, instead of the fallback. Do I lose my account on all the services I signed into?
One thing that I don't see is what happens if I sign up as a user now (with my GMail address) and then GMail later starts providing their own service, instead of the fallback. Do I lose my account on all the services I signed into?
As I understand it, you're identified to the site by an email address. So if GMail becomes an ID provider, you keep using the same identity, but with Google confirming it rather than Mozilla. I'm by no means an expert, though.
Exactly -- your provider's domain is always checked first. Mozilla only steps in as a fallback, and accounts can/will be transparently "upgraded" when a domain adds native support.
I am also by no means an expert but that is also my understanding.
What would change tho is the login procedure. Where once the user saw a Persona login box, suddenly they will see a Gmail login box. That has the potential to be really confusing unless handled well, no?
What would change tho is the login procedure. Where once the user saw a Persona login box, suddenly they will see a Gmail login box. That has the potential to be really confusing unless handled well, no?
Okay, so there's no token being passed? If someone manages to spoof the system, they could be anyone and just accept my access request?
I haven't thought it all through, but it feels like there's a weakness there that's just waiting to be exploited.
I haven't thought it all through, but it feels like there's a weakness there that's just waiting to be exploited.
I think there is a token being passed, but it's authentication, not identity. It's a signed declaration that you own that identity, and it must be either from the domain that issued it, or another source that the site you're visiting specifically trusts (i.e. Mozilla, at present).
I trust Mozilla to have done a good job of this. If there's a weakness, it's not going to be anything so obvious that you can see it from my stumbling attempts to describe the protocol. If it sounds like there is, I'm probably describing it wrong. Have a look at the details here: http://lloyd.io/how-browserid-works
I trust Mozilla to have done a good job of this. If there's a weakness, it's not going to be anything so obvious that you can see it from my stumbling attempts to describe the protocol. If it sounds like there is, I'm probably describing it wrong. Have a look at the details here: http://lloyd.io/how-browserid-works
Thanks. That link explained it, and at least took care of my current worries.
There is a token that's passed. The web site gets an email address and a string called "an assertion" that they must verify.
If Gmail suddenly started verifying instead of Persona for @gmail.com addresses, the web site would see the email address as exactly the same so should give access to the same account.
They would then start verifying that "assertion" using Gmail and not Persona. It would be verified and hence secure.
If Gmail suddenly started verifying instead of Persona for @gmail.com addresses, the web site would see the email address as exactly the same so should give access to the same account.
They would then start verifying that "assertion" using Gmail and not Persona. It would be verified and hence secure.
Chrome, IE, and Opera need to natively incorporate browserid ASAP.
Please, put your egos away and get this done for the sake of everyone who uses the web.
Please, put your egos away and get this done for the sake of everyone who uses the web.
> OpenID uses URLs as identities.
True, the fact that URLs identify them confuses some people. However, http:// being usually superfluous, I don't see why roger.example.com is more confusing than [email protected].
> Most sites would like at least an email address to be able to contact you, so will almost always require an additional step after logging in for the first time.
And openId provides an email if the site asks for it.
> OpenID is a jarring login process.
The difference is that the provider page is a full page rather than a popup?
> Both OpenID and oAuth allow your identity provider (be it Google, Facebook, Twitter) to track every website you sign in to.
So does mozilla persona as your identity provider is your browser ! I remember an opera unite app that acted as an openId provider. How is Persona different/better than that?
> oAuth is complicated for developers to implement [...] several versions of the protocol, [...]
That is true. And it will also be true of persona in two years when you will have to support firefox15 to 20, chrome 33 to 35, ie11, opera14, opera15, webkit-beta-nameless-browser, webkit-alpha-nameless-browser and others' own versions of persona
True, the fact that URLs identify them confuses some people. However, http:// being usually superfluous, I don't see why roger.example.com is more confusing than [email protected].
> Most sites would like at least an email address to be able to contact you, so will almost always require an additional step after logging in for the first time.
And openId provides an email if the site asks for it.
> OpenID is a jarring login process.
The difference is that the provider page is a full page rather than a popup?
> Both OpenID and oAuth allow your identity provider (be it Google, Facebook, Twitter) to track every website you sign in to.
So does mozilla persona as your identity provider is your browser ! I remember an opera unite app that acted as an openId provider. How is Persona different/better than that?
> oAuth is complicated for developers to implement [...] several versions of the protocol, [...]
That is true. And it will also be true of persona in two years when you will have to support firefox15 to 20, chrome 33 to 35, ie11, opera14, opera15, webkit-beta-nameless-browser, webkit-alpha-nameless-browser and others' own versions of persona
> True, the fact that URLs identify them confuses some people. However, http:// being usually superfluous, I don't see why roger.example.com is more confusing than [email protected].
Because roger.example.com is not what most people's OpenID is. Google uses the same OpenID url for all accounts. If you have a Gmail account, your OpenID URL is: https://www.google.com/accounts/o8/id
How the hell can you not find that confusing?
Because roger.example.com is not what most people's OpenID is. Google uses the same OpenID url for all accounts. If you have a Gmail account, your OpenID URL is: https://www.google.com/accounts/o8/id
How the hell can you not find that confusing?
I have been confused about that every, single, damn, time I've ever used Google OpenID, whether it was supporting it or using it. Thanks for opening my eyes.
I knew I liked BrowserID and you've pointed out around reason why.
I knew I liked BrowserID and you've pointed out around reason why.
The big advantage is that users won't have to be 'trained' for anything new: they are all familiar with email / password signups. It's pretty obvious that the website will use your email so no privacy surprises. Switching between email identities is a snap. It's actually pretty pragmatic approach given that what most people do is first assess the website risk, choose whether to give their primary or secondary email (but wait which one? i have 5), type it in (what if they mistype / remember the wrong one) and then type one of their 3-4 rememberable passwords. If anything, browserID neatly simplifies the authentication process for the user.
Also, developers only have an assertion to send; that's really really simple and less likely to break in future releases. Easier signups are important especially for small web utilities that just need a unique identifier and not much private information to work.
Also, developers only have an assertion to send; that's really really simple and less likely to break in future releases. Easier signups are important especially for small web utilities that just need a unique identifier and not much private information to work.
>> Both OpenID and oAuth allow your identity provider (be it Google, Facebook, Twitter) to track every website you sign in to.
> So does mozilla persona as your identity provider is your browser !
https://developer.mozilla.org/en-US/docs/Persona/Implementin...
> True, the fact that URLs identify them confuses some people. However, http:// being usually superfluous, I don't see why roger.example.com is more confusing than [email protected].
Because "roger.example.com" is a webpage, whereas "[email protected]" is an addressbook entry. Very occasionally, "roger.example.com" is a blog or personal webpage and thus probably refers to a single person. Maybe.
Because "roger.example.com" is a webpage, whereas "[email protected]" is an addressbook entry. Very occasionally, "roger.example.com" is a blog or personal webpage and thus probably refers to a single person. Maybe.
additionally, it may be example.com/roger or example.com/openid/roger, the regularity of it is small, and people already know what their email addresses are.
Tying email addresses to a user's identity is a terrible idea.
- I don't want to give my email address to every site I use. It should be available to the site only if I approve their request.
- I use a unique email address for every site that needs one.
- What if I want to start using a new email address?
- I don't want to give my email address to every site I use. It should be available to the site only if I approve their request.
- I use a unique email address for every site that needs one.
- What if I want to start using a new email address?
I wouldn't actually say it's a terrible idea, for 99% of users it should work better, faster, and easier for them, since -very- few people have the same habits as you.
However, having said that, I do otherwise agree with you, I also don't want to give my email out to all of them, and when I do, it may be one of a few address, depending on how much I trust them, or care about the responses. I'm given very little option in that regard.
However, having said that, I do otherwise agree with you, I also don't want to give my email out to all of them, and when I do, it may be one of a few address, depending on how much I trust them, or care about the responses. I'm given very little option in that regard.
> it may be one of a few address, depending on how much I trust them, or care about the responses. I'm given very little option in that regard.
You are given the choice of which email address you want to use to log in. Isn't that exactly what you want?
You are given the choice of which email address you want to use to log in. Isn't that exactly what you want?
I'm curious about that issue, too. Here's a brainstorm:
- An independent Identity Provider (IdP) uses some means of identification for the user (two-factor, iris scan, whatever)
- The IdP provides an anonymized email address to each site that the user logs into.
I'll have to read the spec a bit more to see if that's possible...
- An independent Identity Provider (IdP) uses some means of identification for the user (two-factor, iris scan, whatever)
- The IdP provides an anonymized email address to each site that the user logs into.
I'll have to read the spec a bit more to see if that's possible...
It's hard to do completely cleanly -- building an independent IdP that uses iris scanning or other two-factor systems is totally possible, and actually relatively easy.
Providing anonymized addresses is harder, since your IdP wouldn't be contacted until after the user has selected an address. In that case, you'd want a browser extension that generated addresses conforming to some scheme @youridp.com and automatically filled or selected them in the dialog when using Persona. Totally doable, but that part requires getting out in front of the call to navigator.id.request.
Providing anonymized addresses is harder, since your IdP wouldn't be contacted until after the user has selected an address. In that case, you'd want a browser extension that generated addresses conforming to some scheme @youridp.com and automatically filled or selected them in the dialog when using Persona. Totally doable, but that part requires getting out in front of the call to navigator.id.request.
A well-crafted solution desperately in search of a problem to solve.
If registering at yet another site (forum, online store, government site, etc) and remembering the password when you get back to it 2-3 month after is not a problem for you, I admire your memory. Or maybe you're not visiting these types of sites as much as I do.
Or perhaps he is just doing what everybody _really_ does, which is to use the same username and password for every random site on the net and hope like hell they are not storing passwords in plantext.
A hope, which has been dashed time and time again by bitter reality. It seems the only people lazier about password security than the actual end users, is the site owners ...
A hope, which has been dashed time and time again by bitter reality. It seems the only people lazier about password security than the actual end users, is the site owners ...
But that doesn't work, because every site has slightly different rules about what constitutes a valid password...
Another solution to this is a password manager, eg Keepass. It still centralizes your identity under one roof, in the encrypted DB, but only locally.
But the overhead is much larger and let's be honest, this solution is only used by a tiny minority of (mostly tech) users. Mozilla Persona could be used by everybody because for the end user it is exactly as complex/easy as it is currently or even easier.
Password managers are necessary, but they're not enough. So long as there's an underlying password for every damn site you visit, then every damn site still has to store passwords securely and you have to maintain things when that site gets breached. Not to mention the stability of that password. If it gets sniffed once, it's possibly game over for months. If a Persona assertion gets sniffed in transit, it's only good for a few minutes in time.
Some thoughts from a privacy perspective:
Technically, I think this is vastly superior to the currently available login solutions. But one of the things I never liked about centralised or even federated auth was all the links between accounts.
One thing I don't like: ideally, all a site should need to know is that I'm the same entity I claimed to be last time. I only want to be locally unique on the site, not a globally unique value which can be correlated between sites. Also, it should be my choice as to whether I disclose my email address to sites.
In practice, email addresses are usually required for signups, and it's easy enough to create throwaways. I can absolutely see why it was designed this way, but it would still be nicer if the protocol did not disclose more than it needed to.
In this case, the email address (and equivalently the public key the browser holds for that email address) can be correlated between sites.
I thought a bit about making a mailinator-like IDP (i.e. a convenient way to hack around this). Unfortunately, I can't see a good way right now to get both these properties at the same time:
a) The IDP doesn't know what site (RP) the user is logging in to b) The IDP can auto-generate a persistent unique id for each site (RP) (e.g: <type-4-uuid>@idp...)
I guess the degenerate case would be an IDP which signs <anything@idp...>. Not super useful, but OK for sites where you didn't really want to have a login anyway, I guess... true mailinator style, but for logins.
A few other points:
* Would also be good to have a privacy option to force the browser to generate a fresh keypair every time a new user certificate is requested; at least then we can only be tracked by identity and not so much by device over time as well.
* There is the obvious timing attack, where if the RP doesn't cache the IDP's public key, it may disclose what site the user is logging in to, to the IDP.
* Also, verifier.persona.org will know who is logging in where, if you use their JS (since you pass the assertion and the audience via REST).
* I am not 100% sure at this stage what stops a malicious user from simply asking the browser to perform an identity assertion and grabbing email (or clickjacking the user into doing it) when they already have a user cert; haven't looked at it in depth though.
Technically, I think this is vastly superior to the currently available login solutions. But one of the things I never liked about centralised or even federated auth was all the links between accounts.
One thing I don't like: ideally, all a site should need to know is that I'm the same entity I claimed to be last time. I only want to be locally unique on the site, not a globally unique value which can be correlated between sites. Also, it should be my choice as to whether I disclose my email address to sites.
In practice, email addresses are usually required for signups, and it's easy enough to create throwaways. I can absolutely see why it was designed this way, but it would still be nicer if the protocol did not disclose more than it needed to.
In this case, the email address (and equivalently the public key the browser holds for that email address) can be correlated between sites.
I thought a bit about making a mailinator-like IDP (i.e. a convenient way to hack around this). Unfortunately, I can't see a good way right now to get both these properties at the same time:
a) The IDP doesn't know what site (RP) the user is logging in to b) The IDP can auto-generate a persistent unique id for each site (RP) (e.g: <type-4-uuid>@idp...)
I guess the degenerate case would be an IDP which signs <anything@idp...>. Not super useful, but OK for sites where you didn't really want to have a login anyway, I guess... true mailinator style, but for logins.
A few other points:
* Would also be good to have a privacy option to force the browser to generate a fresh keypair every time a new user certificate is requested; at least then we can only be tracked by identity and not so much by device over time as well.
* There is the obvious timing attack, where if the RP doesn't cache the IDP's public key, it may disclose what site the user is logging in to, to the IDP.
* Also, verifier.persona.org will know who is logging in where, if you use their JS (since you pass the assertion and the audience via REST).
* I am not 100% sure at this stage what stops a malicious user from simply asking the browser to perform an identity assertion and grabbing email (or clickjacking the user into doing it) when they already have a user cert; haven't looked at it in depth though.
If this ever becomes popular, I can imagine law enforcement agencies will want to link e-mail address to people even more, and mail vendors such as Google, Yahoo and Microsoft will become a much more popular target for subpoenas and such.
I just don't like the idea of all the passwords being centralized in one place and being so very easy to obtain by the US Government.
I just don't like the idea of all the passwords being centralized in one place and being so very easy to obtain by the US Government.
I worry about Persona, for exactly the same reason OpenID chose the design it did: It's a serious mistake to permanently tie email to identity.
It's still possible within the framework of Persona to fix this -- the browser / identity provider needs to support freshly-generated opaque "email addresses" for each new site that needs a login. This prevents tracking and spam problems, but will also require both providers and relying parties to downplay the 'email address' token in the UI, which I fear is far too much to ask.
It's still possible within the framework of Persona to fix this -- the browser / identity provider needs to support freshly-generated opaque "email addresses" for each new site that needs a login. This prevents tracking and spam problems, but will also require both providers and relying parties to downplay the 'email address' token in the UI, which I fear is far too much to ask.
Just use <somethinghere>@mockmyid.com.
It doesn't even ask for a password. I don't think it would be too much work to create a Persona service like 33mail.com, which provides your own domain for email and authentication. That way, you would enter "[email protected]", the site would send you there for auth, 33mail would reply that you are logged in to your account (if you were, obviously), and that'd be all.
It doesn't even ask for a password. I don't think it would be too much work to create a Persona service like 33mail.com, which provides your own domain for email and authentication. That way, you would enter "[email protected]", the site would send you there for auth, 33mail would reply that you are logged in to your account (if you were, obviously), and that'd be all.
I am really hoping this takes off. I'm currently implementing it in an app and, although the API is a little awkward, it was pretty easy to do. The only snag I've run into is that it has issues in Chrome if third-party cookies are disabled.