Hacker News Reader

Re: your second point:

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.

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.

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.

> 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.

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.

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.

Fair enough - I'm talking tosh in this instance. Apologies.

Regarding the case-sensitivity issues, this pull request should have fixed all of the outstanding ones: https://github.com/mozilla/browserid/pull/3078

Of course, if you find anything we've missed, please file a bug :)

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).

> 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.

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!

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.

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 ;)

Why, do you have an @spotify.com email address? :P

Yeah but your bridge will still know where I log in, no? I mean, it's great, but it would be even greater if Google supported it natively.

Actually, it won't. You'll OpenID auth into google.login.persona.org, and then get a straight up Persona certificate signed by that fallback, along with all of the privacy safeguards that has.

Oh, very nice. Is there a way to get in the beta?

Honestly, we haven't quite figured out a good way to do a "beta" or partial roll-out for this without breaking other users. Yaaaay decentralization! Instead, we'll be extensively QA'ing it in testing environments, and then we'll flip a big switch to enable it for everyone.

Hopefully Google will do so - and then the bridge can be turned off!

We wouldn't even have to turn it off -- as soon as gmail.com can vouch for its own users, the protocol automatically and preferentially switches over to that. The centralized parts fall away on their own whenever they can. :)

Hear, hear.

EDIT: Oh, can I help beta test it?

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

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.

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/

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.

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.

Check out around 16:00 to 20:30 in my talk: 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.

"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.

> 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.

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_Proje...

>So it can be used not securely? Like OAuth?

So long as you specify your origins properly and properly check the response from their verification service, it's perfectly secure.