Social login buttons aren't worth it
blog.mailchimp.com
blog.mailchimp.com
I don't want to have to socialize my webgraphs to log into your shitty grocery list app. >:(
And when I decide that it's OK to sign up with twitter/fb there are more things that might turn me off:
1) If the app only gathers some info from my twitter/fb account and still wants me to provide an email/password. Sorry, but I was awaiting something simple like 'click authorize in twitter and receive account'. I didn't expect that much effort and I'm closing the tab then.
2) If the app requests to 'post updates to my timeline' or something like that. I'm using twitter/FB as an authorization provider in this case and have no desire that your app will post updates for me. (Possibly in my absence)
username=johnsmith&password=297324khd239723khad7823hksd7gh1h
You could always sniff out if someone has an email address on a lot of systems by visiting the 'forgot your password' page. So perhaps on the account rescue page, just ask for a valid email address, then give a generic thank you message. If the email address exists, send out an email, if not don't bother - but don't give feedback of the sort 'that email address does not exist on the system' etc.
If you are worried about email mistypes then you could always provide a confirmation. However I'd have thought we'd be pretty good at getting our email address right, and the browsers a lot of the time provide a magic autocomplete for email addresses. I guess it just sees a form input name attribute of 'email' and goes by that.
Multiple email addresses are a pain I'll grant you that. But no worse that a multitude of user names.
Perhaps a better message might be:
'If your email address is registered, then we will attempt to send out an email containing a reset code. Please check your inbox.
If you do not receive an email to your given address, then you may not have registered with given email.
Allow time for the arrival of email, and please check your spam folder.'
But it gets a little long winded... I'd almost rather not have a password, and be sent a new code each time (albeit transparently).
I invariably forget passwords and logins frequently. So go through this process like you as a matter of routine.
Bad times potentially though for when your email service is down or when your email address has expired. Or your email account has been exploited.
I realise that we're saying pretty much the same thing, but the design process should be like this:
1. Make the application secure enough so that the cost to a malicious user of cracking the security is greater than the potential value of doing so.
2. Given the constraints of #1, provide the best possible user experience.
Although Mailchimp has a lot of users, it doesn't make sense to generalize conclusions from one SaaS business to the whole web. A private SaaS dashboard is a different use case from most consumer websites, where the goal of logging in with Twitter or Facebook is generally to attach your public identity to your posts or profile on the site, not merely to expedite login. And frankly, a private dashboard is a very strange place to add social login buttons in the first place. Although the "what login did I use?" issue comes up on consumer websites that make good use of social auth, it does so less often, because if you connected a third-party account to one of these sites, you did it for a reason and are more likely to remember.
Like I said then, the social buttons didn't work for MailChimp because they implemented them after most users already had email logins. The article dismisses a concept that is integral to onboarding users at the beginning of your service. When everyone has been using their email login for years, why would they switch? I disagree with some of the people here saying these types wouldn't use a Facebook login. Lots of people use MailChimp; lots of people that have no issue using a Facebook login (and don't understand the risk in doing so).
This is a case of coming to the wrong conclusion with the wrong data.
Well, nobody is perfect, but some are better than others [0]. Security is hard. In my case, I'd trust services like Twitter and Facebook more than myself right now (they have tons of good engineers and much more to lose in case of a security breach). Like many other things, this is a trade-off.
I actually got a little apprehensive about the security of the bridge, and wrote my own IdP you can use for your own domain: https://www.persowna.net/
However, the key thing to realize here is that 3% of mailchimp's users use the social login buttons. That doesn't translate to 3% of your users. One app I work on is a social app for music fans. Most of our users hit the facebook button. It's also mobile, so that might have something to do with it as well (people might not want to type on mobile devices as much)
Takeaway: you need your own stats.
It is basically guaranteed that both Facebook and Twitter logins are more secure than almost any website that might offer one of their login buttons. How many websites have dedicated security engineers? Does mailchimp.com? I doubt it (but I'd be impressed if they do).
The other arguments are pretty reasonable; of course if you don't want to put another brand right in the middle of your login page, a social login button might not be for you. But security is almost an anti-concern: it's probably a win for your users in that respect.
They... almost definitely do. This is no small shop. They have 2M customers, over 150 employees. They have webpages like this one where they talk about their regular pentesting, required security reading for all employees that touch customer data, site certifications and vulnerability disclosure polices -- http://mailchimp.com/about/security/
What is pretty much guaranteed is that there's more people trying to hack Facebook/Twitter security than most smaller sites.
That, and the fact that they're still around means exactly that it is guaranteed they are more secure than most of the smaller sites. Being a big and valuable target to hit, they can only adapt or die.
https://securityledger.com/that-facebook-account-hijack-vuln...
or
http://www.digitaltrends.com/social-media/twitter-was-vulner...
They do. Also they have two-factor authentication.
Of course you also can't ask for any odd permissions either!
Anything relating to my job, I use my work email with a password. Anything personal, if I have the option, I use Facebook and don't let it to post to anyone but me.
Hopefully it will gain traction...
I'd never really thought about this. What do people suggest doing to handle this sort of use case?
For me, adding 'signup with Facebook' has increased the number of registrations. I'll worry about the effect on failed logins when it proves to be a problem.
The solution would be to close that hole, rather than opening the same hole somewhere else. For example, for the username reminder form, if the username can't be found for a given email address, then that can be conveyed to the user by sending them an email message.
I think it's better to assume usernames are publicly available information and atleast get your UX right for the Login Form.
To me, there is especially the case of using a social login to sign up for just trying out a service, which I would not have done if it had meant going through the hassle of filling out a form or even validating en email.
For example, somebody attacking HN can crawl pages such as this one and determine that 'skeletonjelly' is a valid HN user.
It is good guidance, but it's guidance developed with a specific enterprise viewpoint that may not make sense based on the type of service, type of information protected and other controls. For example, multi-factor authentication may be deemed sufficient to control a risk.
As a general principle the concept of "least privilege" is a key component of how security people think. In this case, what is the minimum amount of information that I can provide to the user and still be useful?
From when this was previously discussed (originally published?)