add facebook authentication

[chadwhitacre]

Should be able to authenticate with a Facebook account. If already authenticated, should associated Facebook profile with existing Gittip participant account.

[chadwhitacre]

https://developers.facebook.com/docs/authentication/

[chadwhitacre]

https://developers.facebook.com/docs/authentication/server-side/

[joonas]

What's the status of this? Something we could be looking to do or something to hold off on until #429 is resolved?

[chadwhitacre]

Facebook and Google are the two auth providers I'm interested in. Once we have those two + Twitter and GitHub, I think we're good on auth providers for a while. Given that that's just two more integrations, my hunch is that we could move forward as easily implementing them ourselves as waiting for Singly. Is this something you're interested in taking on, @joonas?

Note that we want an infinite number of integrations under /on/, and maybe Singly helps us with that (though do they have, e.g., Packagist? (#467)). All auth services will also have entries under /on/, but not all /on/ services will be usable for auth. Make sense?

[ceboudreaux]

👍

I'm ready to promote Gittip on Facebook. Lots of people who would register in order to tip me (namely family members) are on Facebook, but not Twitter, Github, etc.

[chadwhitacre]

+1 from CoreyClarkPhD on Twitter.

[greggles]

+1 from me, for what it's worth. I agree with @ceboudreaux that Facebook is likely to have more givers.

[chadwhitacre]

+1 from Emir Hayric on Twitter.

[clone1018]

I'll be working on this during the weekend.

[clone1018]

Disregard.

[pjf]

+1 from yours truly. Many of my supporters are non-technical folk, and Google/Facebook are their most accessible means of using gittip.

[chadwhitacre]

Here's a word of caution from @homakov about supporting Facebook Connect:

Every website with "Connect your Facebook to main account to login faster" functionality is vulnerable to account hijacking as long as attacker can replace your identity on Facebook with his identity and connect their Facebook account to victim's account on the website just loading CLIENT/fb/connect URL.

Mitigation: require CSRF token for adding a social connection. E.g. instead of /connect/facebook use /connect/facebook?authenticity_token=123qwe. It will make it impossible for an attacker to start the process by himself.

http://homakov.blogspot.ro/2014/01/two-severe-wontfix-vulnerabilities-in.html

[chadwhitacre]

Conclusion:

In my opinion I'd recommend not using Facebook Connect in critical applications (nor with any other OAuth provider). Perhaps it's suitable quick login for a funny social game but never for a website with important data. Use oldschool passwords instead.

Sound familiar, @zwn? ;-)

Password auth: #1052.

[chadwhitacre]

P.S. Twitter/@Doulittle tipped me off to @homakov's article.

[greggles]

Oauth haters gonna hate. Passwords alone are certainly flawed as well. Does gittip have brute force detection? Multi factor auth? Is gittip more or less likely to build that than the Oauth providers? When I do Oauth to Facebook/Twitter/Github/Google it involves multi-factor auth and they protect against brute force attacks on accounts. Those are a security level beyond what most sites are going to offer.

Reading the homakov article it seems to require a few things:

1. An open redirect that is a 302 on the victim site. Why not just work to avoid open redirects?
2. An account on victim site that is not already authed to the oauth provider - again, there are several options here to prevent this problem, like making the initiation of a facebook connect protected with csrf nonce.
3. The comments from Feb 8th/9th/10th seem to indicate that the connection might be made but without any permissions. Messaging to a site member via email "Thanks, you just connected your Facebook account." could help mitigate the damage since the person is already online.

Be wary of the headlines in security articles. It's common to state the worst case scenario, but the details often make it virtually impossible to exploit and/or easy to mitigate.

[chadwhitacre]

Be wary of the headlines in security articles. It's common to state the worst case scenario, but the details often make it virtually impossible to exploit and/or easy to mitigate.

@Changaco Does #1369 address the mitigation mentioned at #30 (comment)?

[Changaco]

@whit537 Yes, I think so. The links to sign in or connect with an elsewhere account have been replaced by POST forms with CSRF tokens.

[greggles]

If I review my own mitigations in reverse order:
3. is not going to happen until you have email addresses (and maybe not even then, since it could be seen as an annoying message).
2. Seems like it is handled per @Changaco's comment

1. Do you have open redirects? Is there anything that sets a Location: header with user supplied text that can take someone off site? If there is then you should fix that on its own regardless of this issue. If there aren't any ...then don't let this article slow down your deployment of additional solutions.

This could also be a good time to make a policy decision about subdomains for things. e.g. should building.gittip.com really be buildinggittip.com to reduce the attack surface?

[zbynekwinkler]

http://homakov.blogspot.ro/2014/01/two-severe-wontfix-vulnerabilities-in.html

I will have to read it several times, I have a hard time understanding it.

[homakov]

1. An open redirect that is a 302 on the victim site. Why not just work to avoid open redirects?

No, redirect is required for issue 2.

like making the initiation of a facebook connect protected with csrf nonce.

this is protection i was talking about

but the details often make it virtually impossible to exploit and/or easy to mitigate

Not for my articles

[chadwhitacre]

The links to sign in or connect with an elsewhere account have been replaced by POST forms with CSRF tokens.

@Changaco But could a GET be crafted that circumvents the CSRF protection? And does that matter?

Do you have open redirects? Is there anything that sets a Location: header with user supplied text that can take someone off site?

I can't confidently answer this right now. Audit required. Reticketed as #2138.

This could also be a good time to make a policy decision about subdomains for things. e.g. should building.gittip.com really be buildinggittip.com to reduce the attack surface?

Maybe. Reticketed as #2139.

[seanlinsley]

This is labeled as 3 - Work in Progress but no one's assigned? I'm gonna remove it from Huboard.

[rcross]

just adding +1 from me. I think getting facebook connect and/or any other authentication options that are more mainstream and less dev-centric are a huge factor for wider appeal of gittip.

[chadwhitacre]

+1 from @CCsolidarity on Twitter.

[duckinator]

+1 from @VeganNook on Twitter.