integrate with Mozilla Persona

[chadwhitacre]

Per @buchuki

[chadwhitacre]

+1 from @msenateatplos on #1264.

[seanlinsley]

BTW @whit537 the title for this ticket is misspelled. Personas should be singular.

[seanlinsley]

Quoting myself from #583:

Ah, it looks like GitHub allows email scraping but Twitter doesn't. I can't seem to find any reference for Bitbucket, so I'm going to assume they don't allow it.

If I were to have my way, I'd disable (or provide a mechanism for users to disable) authentication via other services. Instead you'd log in via Persona (try this quick demo), which is entirely dependent on your email account, and then use OAuth for other services merely to prove that you own the given account.

[jonathan-s]

I think I would agree with this. Persona seems to be a neat oAuth. Once you've signed up you could get re-directed to a page where you can fill in the other oAuth services for further verification of yourself.

[chadwhitacre]

@daxter Fixed the title, thanksorry.

I'm open to this but seems like refactoring accounts elsewhere comes first.

[chadwhitacre]

Actually, it seems like this would replace our accounts elsewhere code, potentially? Or seriously affect it, yes?

[seanlinsley]

It depends on whether we make Persona the only way to authenticate, and thus making OAuth for Twitter, etc. only for proving that you own a given account.

I haven't looked at the current accounts code in detail; was there a specific refactoring you were thinking of in your first comment?

[chadwhitacre]

@daxter Does Persona give us an API to determine what OAuth accounts a person has linked to their Persona?

Yes. @lyndsysimon started working on this on a fork eight months ago, and two months ago I brought that work into a branch on the main repo here. I neglected to kick off a PR at that time; I've done so now: #1369.

[seanlinsley]

First two useful links to find more information on Persona: the wiki and the blog.

So, Mozilla created a cryptographic protocol for asserting the ownership of an email address. This is based around Identity Providers (IdPs), which are nominally the organizations that host that given email domain. When a domain doesn't have an IdP set up, Persona defaults to sending an email to the user to confirm ownership. Currently though a good chunk of email users get the easiest UI flow of 2-3 mouse clicks because both Google and Yahoo have set up their own IdPs. Two good links to learn more are the official BrowserID spec and the mid-level protocol overview.

More links:

• Quick Setup
• The implementer's guide
• Security considerations
• The FAQ

TL;DR, @whit537: Persona does nothing more than prove ownership of an email address, so to prove ownership of Twitter, GitHub etc. accounts we'd still have to use OAuth.

[chadwhitacre]

@daxter Okay, that's significantly less useful than I'd hoped, then.

[seanlinsley]

How about this then: what are your goals? I've already expressed mine.

[seanlinsley]

For example: how do you feel about switching the roles so that Persona is used for auth and OAuth is used to show who you are on other services?

[mvdkleijn]

Just to chime in here... Using only Persona would be tantamount to vendor lock-in. Something I believe is a bad thing. Also, it forces people (who might, for some reason, not like it) to use Persona.

As an alternative, we can push Persona as the preferred method of authentication (if we're convinced its useful) and still allow others like Github, Bitbucket, etc. Just emphasize them less.

From what I can tell, Persona is only interesting in verifying that someone has registered on the Persona site with a certain email. However, Gittip's reasons for using Github, Bitbucket and Twitter are to prove, publicly, that someone's Gittip account is for the same person behind that Github, etc account they like so much. So connecting the Github etc accounts would still be necessary in my view.

[seanlinsley]

Persona was built specifically to prevent vendor lock-in. Anyone can run an IdP; it's all open source. The whole point of using Persona is it allows you to authenticate a user, and know they own that email address, without requiring that they actually enter a password.

I'm not suggesting that we get rid of OAuth for services like GitHub and Twitter, merely that we don't use them for authentication. We'd still use them to prove that a given user owns a given external account, just like we do today.

And just to clarify, I'm not necessarily against continuing to allow authentication via those services; I just think that allowing it makes the user experience unnecessarily complex.

But then again, I'm reminded of #583. Since we deal with financial transactions we really need an email address to get ahold of our users with. Not all OAuth providers give us access to the user's email (Twitter, for example), so it'd be easier if our authentication scheme inherently and always grabbed the user's email address.

[mvdkleijn]

Ok, then we're saying the same thing I guess. Just as long as we keep in mind that Persona validates email ownership, so it authorizes a user for a service, it doesn't provide identity confirmation.

[ssokolow]

If Gittip goes to Persona exclusively, that'll be the last you see of me. (Not that it'll be a big loss yet.)

As is, it has two deal-breaking flaws (that I tried to report on gmane.comp.mozilla.identity.devel but which got swallowed by a mess-up on my part and I'm still waiting for a response from GMane on the topic since Thunderbird doesn't appear to have a "Sent Messages" box for NNTP):

1. If you set browser.link.open_newwindow=1 in Firefox or use a browser extension which replicates the same "force window.open() and target='...' to navigate the current tab instead" behaviour, the Personal login UI is unusably broken.

   (You can't middle-click Persona buttons and left-clicking results in a blank dialog. I encounter sites which try to force new tabs so frequently that I'd rather shun Persona than unset that tweak.)

2. Persona interacts poorly at best with users like me who give every site a different e-mail alias and treat them like API keys to be revoked if spam starts to arrive via them.

   (So GitHub, BitBucket, Twitter, and Bountysource all know me under different e-mail addresses and I'd give Gittip a different e-mail if I could. As is, I just treat the address I give to GitHub as highly untrustworthy since, among other things, they were embedding it into web-made commits until recently.)

[callahad]

@ssokolow We have preliminary work that allows Persona to function in environments without popups (iOS Chrome, Windows Phone, etc.) that could potentially be re-purposed to address your first concern. There are limitations to what we can do when window.open is intentionally broken by a user or addon, but fortunately this is rare.

As to working well with many addresses, please contact me privately (my username at mozilla.com) so we can make sure we've got a record of what does and doesn't work well for you. Persona should remember your preferred email address for each individual site, but maybe we could do that better?

[lloyd]

Interestingly, once a verified email is provided by persona, it seems like the user search api can be used to associate it with the github user name. Dunno how well verified the public email address of a user is on github, but it could be something to explore as a way to ask the user only for an email, and link to github as a magic side-effect.

curl -H 'Accept: application/vnd.github.preview' https://api.github.com/search/[email protected]%20in:email

[ssokolow]

@lloyd:

What benefits would that have over the current system?

I know I'm a bit of a broken record on the issue, but the only change I see is the downside that I'd probably give Gittip a unique alias and then run up against "We couldn't find your GitHub account" while the OAuth approach is just "click two buttons and the accounts are paired."

[greggles]

It provides UX flow that 99% of people would appreciate. If there is a fallback to the OAuth approach on github it seems fine to me.

[ssokolow]

@greggles:

I understand that. I just don't understand whether it provides any benefit over using the "click two buttons and you're done" interaction for an OAuth provider like GitHub which allows e-mail scraping.

[lloyd]

hmm. does bit bucket have a search by email function? would "tip by email" be interesting?

just thinking out loud - I dig merit based crowd funding.

[mvdkleijn]

hmmm I wouldn't appreciate automatic linking of my third party accounts to my gittip account.. I like being in control myself. If I want to link my GitHub but not my BitBucket, for whatever reason, Gittip should respect that and not auto-link it.

And to be honest, I don't see the added value of yet another "single point of authentication"...

[callahad]

This may not be the right place to have this discussion, sorry for the noise!

I don't see the added value of yet another "single point of authentication"...

Persona is just trying to take the password out of traditional "email + password" login systems.

If Gittip is happy with only offering provider-specific OAuth login options, then Persona doesn't add a ton of value. If Gittip is considering a traditional / freeform / user-driven login option ("email + password"), then Persona should be a great fit. It lets people use any email address they want, and Gittip never needs to touch a password again.

[chadwhitacre]

If Gittip is happy with only offering provider-specific OAuth login options, then Persona doesn't add a ton of value. If Gittip is considering a traditional / freeform / user-driven login option ("email + password"), then Persona should be a great fit. It lets people use any email address they want, and Gittip never needs to touch a password again.

Thanks for the clarification, @callahad. This helps me a lot.

We're not planning to provide email-only login in the near future, because social accounts are central to our anti-fraud systems (more discussion on #89). So I'm going to go ahead and close this ticket. If email-only sign-ups on Gittip ever pick up enough momentum, let's revisit Persona.

[seanlinsley]

@whit537 implementing Persona doesn't have to mean email-only login. Towards #89, Persona is without a doubt the easiest way to authenticate through your email account.

[seanlinsley]

And to clarify @callahad, Gittip doesn't currently deal with any passwords. Right now, the only way to log in is via external services like GitHub or Twitter.

[chadwhitacre]

@daxter Right. We're not planning to allow people to authenticate via email, only via Twitter, GitHub, Bitbucket, Facebook, and Google. (Maybe Yahoo or Microsoft someday?)

[seanlinsley]

Oh? That's the first I've heard that. What exactly is the reason?

Quite a few people in #89 argue that auth via email is insecure, but the current scheme is considerably less so as it only takes one external account (each of which nominally require a password, and thus are vulnerable to attack) in order to compromise to your Gittip account.

As well, we're relying on each external service's implementation of OAuth. That's a large surface area for attack. This problem only gets worse if we start supporting more services.

Instead of e.g. implementing dual-factor authentication via Yubikeys as has been suggested before, we could just use Persona and let the individual user decide how much security they want. For example, by using Google's dual-factor auth.

[chadwhitacre]

but the current scheme is considerably less so as it only takes one external account (each of which nominally require a password, and thus are vulnerable to attack) in order to compromise to your Gittip account.

This is false. An email-based Gittip account would have the email account as a single point of failure, so it is not "considerably" more secure in this regard than a social-based Gittip account.

As well, we're relying on each external service's implementation of OAuth. That's a large surface area for attack. This problem only gets worse if we start supporting more services.

The plan is to only permit certain OAuth implementations to be usable for authentication, namely the big ones: Twitter, Facebook, Google (I feel okay about GitHub. I feel iff-y about Bitbucket). We'll allow many, many more OAuth providers to be usable to connect an account to a Gittip account even if it's not usable for authentication to Gittip.

Down the road perhaps we can use multiple social accounts in multi-factor auth (along with SMS).

The bottom line here is anti-fraud. With social-based Gittip accounts we have a whole new set of fraud signals to work with that simply don't exist with email-based accounts. The two matters are entangled for us, and our current strategy "ain't broke," as they say.

[callahad]

We'll allow many, many more OAuth providers to be usable to connect an account to a Gittip account even if it's not usable for authentication to Gittip.

Oh? Persona may offers significant user experience improvements for this case. Similar to AirBNB, you could allow people to authenticate with an email address to avoid NASCAR-esque login screens, and then give that user the ability to hang multiple social authorizations off of that account.

It avoids the "I have all of these accounts, which should I pick?" and "Which did I pick last time?" problems, as well as sidestepping counter-intuitive processes like signing in with GitHub in order to accept tips on a Bitbucket account.

Anywho, y'all have enough on your plate to where I won't belabor the point. If Gittip decides to explore Persona, the team is standing by to help. Otherwise, see you at PyCon in April? :)

[seanlinsley]

but the current scheme is considerably less so as it only takes one external account (each of which nominally require a password, and thus are vulnerable to attack) in order to compromise to your Gittip account.

This is false. An email-based Gittip account would have the email account as a single point of failure, so it is not "considerably" more secure in this regard than a social-based Gittip account.

The argument here is single point of failure vs large surface area for attack. It seems to me that the large surface area is a much higher risk. After all, it only takes one weak password for an external service (or a badly implemented auth scheme by that service) in order for your Gittip account to be compromised.

I don't know about you, but I have more secure authentication set up for my email than I do for everyday social services.

At any rate, thanks for taking the time to talk with us @callahad 🐙

[zbynekwinkler]

Social accounts hang of the email anyway. When ones email is compromised, the social accounts can easily follow but not the other way around. Therefore adding email sign in IMHO does not increase the risk. We could allow email sign in but allow credits and withdrawals only after attaching some social account (thus not using any social account for sign in). Having the ability to decrease the number of ways one can sign it would also help lower the risks.

[lloyd]

FWIW, sorry for conflating linking with sign in - I fear I confused the conversation a bit. As @callahad said, we're here to help if there's anyway we can with Persona and a privacy preserving alternative way to sign-in to gittip (and I dig @zwn's compromise).

[clone1018]

We're reopening this as a new auth method, more details coming from the contributor soon.

[zbynekwinkler]

http://en.wikipedia.org/wiki/Mozilla_Persona#Identity_Bridging

Mozilla announced "Identity Bridging" support for Persona in July, 2013: As they describe on their blog: "Traditionally...Mozilla would send you an email and ask you to click on the confirmation link it contained.With Identity Bridging, Persona learned a new trick; instead of sending confirmation emails, Persona can ask you to verify your identity via your email provider’s existing OpenID or OAuth gateway." This announcement included support for existing users of the Yahoo Mail service. In August 2013, Mozilla announced support for Identity Bridging with all Gmail accounts. They wrote in this additional announcement that "combined with our Identity Bridge for Yahoo, Persona now natively supports more than 700,000,000 active email users. That covers roughly 60-80% of people on most North American websites."

[chadwhitacre]

I've assigned this two stars.

[chadwhitacre]

"Why we love Mozilla Persona. And why you should, too."
http://blog.zonino.co.uk/why-we-love-mozilla-persona-and-why-you-should-too/

[zbynekwinkler]

http://benjamin.smedbergs.us/blog/2014-02-11/dont-use-mozilla-persona-to-secure-high-value-data/

Persona is a great system for the multitude of lower-value accounts people keep on the internet.
For any site with high-value data, Persona is not a good choice.

[chadwhitacre]

But ...

It would be very interesting to combine Persona with some other authentication system such as client certificates or a two-factor system. This would allow most users to use the simple login system, while providing extra security properties when users start to access high-value resources.

[seanlinsley]

The comments on that blog post, and on Hacker News, are worth a read.

A more PR-friendly headline would be, "Use Two-Factor Authentication to Secure High-Value Data." Persona is not the problem.

[zbynekwinkler]

So that would be #638.

[Changaco]

Persona doesn't look like a very good fit for Gratipay, because we already have email addresses for most of our users, but we haven't verified them yet. Persona is designed to verify the email address of a user at sign-up, I doubt that we can do a bulk verification of email addresses we already have, so it's probably going to be simpler for us to implement the traditional email+password authentication.

Closing, feel free to reopen if you disagree.