5 ms·

In case you're not familiar with them, this blog comes from the Mozilla Identity team, which is creating a unified login product called "Persona." It's basicall

In case you're not familiar with them, this blog comes from the Mozilla Identity team, which is creating a unified login product called "Persona." It's basically the features of social login (you don't have to create a new account for every site) without the drawbacks (an advertising-driven company knowing your every login). I use Persona on my costs-real-money subscription site[1] and I'm very happy with it. Integration was easy, the user experience is pretty good, and it's been stable and reliable. The best thing, of course, was not having to implement my own password-management infrastructure, which saved me a ton of time, as well as insulating me from the hard security problems that come along with such a beast. If you decide to try Persona, I heartily recommend it. There are a couple of gotchas to be aware of: 1- On iOS, only Safari works due to Persona using a pop-up window for login. People using Chrome on iOS will get a confusing "relay frame not found" error. 2- Signup flow could be better. When users create an account, they get a confirmation email. Clicking the link in that confirmation email redirects them to the Persona site, not back to your site. It's possible this is configurable and I haven't figured it out yet. 3- Persona emails are case-sensitive. There's some rare issues that occur as a result. At one point, it could crash the login, but I believe that's been fixed. Don't let these flaws stop you, though--Persona is very well done and constantly getting better. I've had hundreds of people sign up for paid accounts and only two have had trouble to the point of asking for help. (And nobody's cancelled their subscription because of login problems. :-) ) [1] Let's Code Test-Driven JavaScript, letscodejavascript.com

judofyr 14y ago
Re: your second point: https://developer.mozilla.org/en-US/docs/DOM/navigator.id.request https://developer.mozilla.org/en-US/docs/DOM/navigator.id.re... > returnTo: Absolute path to send new users to after they've completed email verification for the first time. The path must begin with '/'. This parameter only affects users who are certified by Mozilla's fallback Identity Provider.
- zimbatm 14y ago
  I wonder how confusing for the user it is to subscribe to site A and receive a confirmation email from Person instead of that site.
  - th5 14y ago
    shouldnt be too bad, because the button they click to login says "Persona," as does the email. I guess if a person is already familiar with logging via fb/google/twitter, then they should "get it." but someone not familiar with logging to site A using credentials from site B.... yea i can see that being confusing.
fmarier 14y ago
Regarding the case-sensitivity issues, this pull request should have fixed all of the outstanding ones: https://github.com/mozilla/browserid/pull/3078 https://github.com/mozilla/browserid/pull/3078 Of course, if you find anything we've missed, please file a bug :)
callahad 14y ago
> 2- Signup flow could be better. Upgrade to the Observer API (`.watch` and `.request`) and your users will automatically get a super smooth post-verification experience, just like you described.
basicallydan 14y ago
Thank you for providing a link to try it out :) I like it a lot, but at the end of the day I'm still relying on a single company to hold the keys to many accounts of mine on the web, which is still a bit jarring (not that it's going to stop me).
- callahad 14y ago
  > at the end of the day I'm still relying on a single company to hold the keys to many accounts Actually, with Persona, you're not. :) Persona has a fully decentralized architecture. The centralization you're seeing right now is completely temporary, and only serves as a bootstrapping convenience. If you own your own domain you can turn it into a Persona Identity Provider and start minting your own identity certificates today, without Mozilla (or any other single company) being forced into the trust path.
  - basicallydan 14y ago
    Aha, it's for Bootstrapping! Awesome, good to hear. I saw the thing about Identity Providers and got excited, but then I logged in and was like... aww.. So, hopefully Google will be doing it soon with Gmail/Google Apps!
    - callahad 14y ago
      We're going to build a Persona <-> Gmail OpenID bridge soon. Probably launching in May or June. It'll almost be like Google supports it directly. :) After that will come Google Apps support.
      - basicallydan 14y ago
        You, sir, are a gentleman and a scholar. I'll submit a feature request to Spotify to get them to support Persona log in. When Gmail and Spotify are gone I'll be two big steps closer to getting rid of that pesky Facebook account ;)
        14y ago
ancarda 14y ago
I'm interested to know how Persona works server-side? AFAIK, it's entirely done in JavaScript. I can't imagine sending the browser ID over Ajax to make a session, it seems far too easy to exploit. Perhaps I'm missing something.
- callahad 14y ago
  Check out around 16:00 to 20:30 in my talk: http://pyvideo.org/video/1764 http://pyvideo.org/video/1764 In short: it's bog standard public key cryptography. My browser has a keypair and my email provider has a keypair. My public key and email address are bound together and signed by my email provider's private key. When I want to log into a site, I pass along that certificate. I also pass along a document containing where I want to log in and and the current time, signed by my browser's private key. The latter document ties a given login request to a specific keypair. The former document ties a given keypair to an email address. Together, they identify me and prove that the person logging in really is the same person that was authenticated by the email provider.
tracker1 14y ago
One note... I really don't like that there's no mention of subscription pricing before giving you information.
- jdlshore 14y ago
  It was in the first paragraph of the "subscribe" page. But I've modified the page to make it more obvious. Thanks for the feedback.
  - tracker1 14y ago
    Sorry, it wasn't very obvious... I would suggest putting the pricing in bold text near the pay with credit card button... perhaps an additional field: Email: [_____________] Confirm Email: [________________] Subscription: $24.95/Month (after free 7-day trial) I tend to be suspicious when the price isn't at least as conspicuous as the biggest/boldest text. Example: http://www.roadreadycertified.com/ http://www.roadreadycertified.com/
    - jdlshore 14y ago
      Thanks for the suggestion. I'll keep tweaking it. I'm seeing fewer (actually, none) bounces off the payment page than before, which suggests that the change I made has already helped. I'm limited by a serious lack of graphic design skill, and this page wasn't part of Primate's original design work for the site. It shows. :-) It will get a proper design at some point in the future.
adrianhoward 14y ago
Don't let these flaws stop you, though--Persona is very well done and constantly getting better. I've had hundreds of people sign up for paid accounts and only two have had trouble to the point of asking for help. (And nobody's cancelled their subscription because of login problems. :-) ) Just as a point of info "only two have had trouble to the point of asking for help" is a really bad way of judging whether something is working well or not for your customers. The vast majority of people do not complain if they hit problems. They just silently go away. From my experiences of optimising this sort of stuff I'd pretty much guarantee that you have at least 10x times than number failing and walking. Possibly much higher.
- jdlshore 14y ago
  Not in this case. The signup flow for my site is "decide to subscribe, put in email address, put in credit card, create Persona account." By the time they get to the "create Persona account" part, they're already invested in it working. I also monitor my logs for signs of trouble. One of the two issues I was talking about above was actually initiated by me reaching out to the subscriber. (I happened to see them bouncing on the "now log in" page within a few minutes of their subscribing.) And I also ask people who cancel why they did so. The vast majority respond, and none have said "I couldn't log in." :-) It's quite possible there are still some angry silent unsubscribers who were stymied by Persona, but at this point I'm satisfied that it's not a significant number.
  - adrianhoward 14y ago
    Fair enough - I'm talking tosh in this instance. Apologies.
martinced 14y ago
"not having to implement my own password-management infrastructure, ..., as well as insulating me from the hard security problems that come along with such a beast." But you do realize it does definitely create another, much more serious, security problems right? What happens when the single sign-on server gets compromised? What happens when tokens aren't as secure as they should (like the recent OAuth SNAFUs, with an 's')? What happens when you don't pay attention to all the fineprints in the Persona docs stating things like: "Be careful if you don't do this it's going to be easy to forge" and: "Guidelines to use Persona securely" ? So it can be used not securely? Like OAuth? Do you think I find it re-assuring that I have to take steps so that things are not easy to forge? What when the latest JavaScript / browser exploits manages to forge requests? Don't get me wrong: this seems very convenient. But you're trading time for something here. It saves you time by now having to roll your own security correctly (a DB into which you put emails and bcrypt encrypted passwords) but it comes at a price. The price is the added insecurity that single sign-on adds.
- jdlshore 14y ago
  Authentication requires attention to security no matter how do it. There's no silver bullet. As far as I can tell, using Persona requires less attention to security than doing it myself. I don't see how that translates to creating "much more serious" security problems. Perhaps you are a security expert who can do a better job than a team of Mozilla developers who are dedicating themselves full-time to solving authentication problems. I'm not. I know enough to know that security is harder than it looks, and that even if I salt my fries and crypt my bees, I can still screw things up[1]. Better to outsource it... well, as much as I can, anyway. [1] https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Proje...
- callahad 14y ago
  > What happens when the single sign-on server gets compromised? Persona has a federated architecture. In the very near future, most users will not be vouched for by a central authority. > bcrypt encrypted passwords Don't forget to upgrade everyone to scrypt when that recommendation changes.
- 14y ago

judofyr 14y ago

Re: your second point: https://developer.mozilla.org/en-US/docs/DOM/navigator.id.request https://developer.mozilla.org/en-US/docs/DOM/navigator.id.re... > returnTo: Absolute path to send new users to after they've completed email verification for the first time. The path must begin with '/'. This parameter only affects users who are certified by Mozilla's fallback Identity Provider.

zimbatm 14y ago
I wonder how confusing for the user it is to subscribe to site A and receive a confirmation email from Person instead of that site.
- th5 14y ago
  shouldnt be too bad, because the button they click to login says "Persona," as does the email. I guess if a person is already familiar with logging via fb/google/twitter, then they should "get it." but someone not familiar with logging to site A using credentials from site B.... yea i can see that being confusing.

fmarier 14y ago

Regarding the case-sensitivity issues, this pull request should have fixed all of the outstanding ones: https://github.com/mozilla/browserid/pull/3078 https://github.com/mozilla/browserid/pull/3078 Of course, if you find anything we've missed, please file a bug :)

callahad 14y ago

> 2- Signup flow could be better. Upgrade to the Observer API (`.watch` and `.request`) and your users will automatically get a super smooth post-verification experience, just like you described.

basicallydan 14y ago

Thank you for providing a link to try it out :) I like it a lot, but at the end of the day I'm still relying on a single company to hold the keys to many accounts of mine on the web, which is still a bit jarring (not that it's going to stop me).

callahad 14y ago
> at the end of the day I'm still relying on a single company to hold the keys to many accounts Actually, with Persona, you're not. :) Persona has a fully decentralized architecture. The centralization you're seeing right now is completely temporary, and only serves as a bootstrapping convenience. If you own your own domain you can turn it into a Persona Identity Provider and start minting your own identity certificates today, without Mozilla (or any other single company) being forced into the trust path.
- basicallydan 14y ago
  Aha, it's for Bootstrapping! Awesome, good to hear. I saw the thing about Identity Providers and got excited, but then I logged in and was like... aww.. So, hopefully Google will be doing it soon with Gmail/Google Apps!
  - callahad 14y ago
    We're going to build a Persona <-> Gmail OpenID bridge soon. Probably launching in May or June. It'll almost be like Google supports it directly. :) After that will come Google Apps support.
    - basicallydan 14y ago
      You, sir, are a gentleman and a scholar. I'll submit a feature request to Spotify to get them to support Persona log in. When Gmail and Spotify are gone I'll be two big steps closer to getting rid of that pesky Facebook account ;)
      - 14y ago

ancarda 14y ago

I'm interested to know how Persona works server-side? AFAIK, it's entirely done in JavaScript. I can't imagine sending the browser ID over Ajax to make a session, it seems far too easy to exploit. Perhaps I'm missing something.

callahad 14y ago
Check out around 16:00 to 20:30 in my talk: http://pyvideo.org/video/1764 http://pyvideo.org/video/1764 In short: it's bog standard public key cryptography. My browser has a keypair and my email provider has a keypair. My public key and email address are bound together and signed by my email provider's private key. When I want to log into a site, I pass along that certificate. I also pass along a document containing where I want to log in and and the current time, signed by my browser's private key. The latter document ties a given login request to a specific keypair. The former document ties a given keypair to an email address. Together, they identify me and prove that the person logging in really is the same person that was authenticated by the email provider.

tracker1 14y ago

One note... I really don't like that there's no mention of subscription pricing before giving you information.

jdlshore 14y ago
It was in the first paragraph of the "subscribe" page. But I've modified the page to make it more obvious. Thanks for the feedback.
- tracker1 14y ago
  Sorry, it wasn't very obvious... I would suggest putting the pricing in bold text near the pay with credit card button... perhaps an additional field: Email: [_____________] Confirm Email: [________________] Subscription: $24.95/Month (after free 7-day trial) I tend to be suspicious when the price isn't at least as conspicuous as the biggest/boldest text. Example: http://www.roadreadycertified.com/ http://www.roadreadycertified.com/
  - jdlshore 14y ago
    Thanks for the suggestion. I'll keep tweaking it. I'm seeing fewer (actually, none) bounces off the payment page than before, which suggests that the change I made has already helped. I'm limited by a serious lack of graphic design skill, and this page wasn't part of Primate's original design work for the site. It shows. :-) It will get a proper design at some point in the future.

adrianhoward 14y ago

Don't let these flaws stop you, though--Persona is very well done and constantly getting better. I've had hundreds of people sign up for paid accounts and only two have had trouble to the point of asking for help. (And nobody's cancelled their subscription because of login problems. :-) ) Just as a point of info "only two have had trouble to the point of asking for help" is a really bad way of judging whether something is working well or not for your customers. The vast majority of people do not complain if they hit problems. They just silently go away. From my experiences of optimising this sort of stuff I'd pretty much guarantee that you have at least 10x times than number failing and walking. Possibly much higher.

jdlshore 14y ago
Not in this case. The signup flow for my site is "decide to subscribe, put in email address, put in credit card, create Persona account." By the time they get to the "create Persona account" part, they're already invested in it working. I also monitor my logs for signs of trouble. One of the two issues I was talking about above was actually initiated by me reaching out to the subscriber. (I happened to see them bouncing on the "now log in" page within a few minutes of their subscribing.) And I also ask people who cancel why they did so. The vast majority respond, and none have said "I couldn't log in." :-) It's quite possible there are still some angry silent unsubscribers who were stymied by Persona, but at this point I'm satisfied that it's not a significant number.
- adrianhoward 14y ago
  Fair enough - I'm talking tosh in this instance. Apologies.

martinced 14y ago

"not having to implement my own password-management infrastructure, ..., as well as insulating me from the hard security problems that come along with such a beast." But you do realize it does definitely create another, much more serious, security problems right? What happens when the single sign-on server gets compromised? What happens when tokens aren't as secure as they should (like the recent OAuth SNAFUs, with an 's')? What happens when you don't pay attention to all the fineprints in the Persona docs stating things like: "Be careful if you don't do this it's going to be easy to forge" and: "Guidelines to use Persona securely" ? So it can be used not securely? Like OAuth? Do you think I find it re-assuring that I have to take steps so that things are not easy to forge? What when the latest JavaScript / browser exploits manages to forge requests? Don't get me wrong: this seems very convenient. But you're trading time for something here. It saves you time by now having to roll your own security correctly (a DB into which you put emails and bcrypt encrypted passwords) but it comes at a price. The price is the added insecurity that single sign-on adds.

jdlshore 14y ago
Authentication requires attention to security no matter how do it. There's no silver bullet. As far as I can tell, using Persona requires less attention to security than doing it myself. I don't see how that translates to creating "much more serious" security problems. Perhaps you are a security expert who can do a better job than a team of Mozilla developers who are dedicating themselves full-time to solving authentication problems. I'm not. I know enough to know that security is harder than it looks, and that even if I salt my fries and crypt my bees, I can still screw things up[1]. Better to outsource it... well, as much as I can, anyway. [1] https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Proje...
callahad 14y ago
> What happens when the single sign-on server gets compromised? Persona has a federated architecture. In the very near future, most users will not be vouched for by a central authority. > bcrypt encrypted passwords Don't forget to upgrade everyone to scrypt when that recommendation changes.
14y ago