Social Login Buttons Aren't Worth It (2012)(blog.mailchimp.com)
blog.mailchimp.com
Social Login Buttons Aren't Worth It (2012)
http://blog.mailchimp.com/social-login-buttons-arent-worth-it/
75 comments
From my experience with a B2C site, we see around 50% use password and 50% use social logins.
The problem however is that people easily forget what they used to login with, and when they try things like a password reset, we can't really reset their passwords if they used social logins. Or they might forget whether they used google or facebook to login...
So the main problem that I personally have with social logins is that they create fragmentation, and a simple login form becomes a memory-exercise for the user.
The problem however is that people easily forget what they used to login with, and when they try things like a password reset, we can't really reset their passwords if they used social logins. Or they might forget whether they used google or facebook to login...
So the main problem that I personally have with social logins is that they create fragmentation, and a simple login form becomes a memory-exercise for the user.
This is actually a pain point our company (https://www.dailycred.com) solves.
If a user forgets the method they used to sign up, we'll still return the right user record to your app.
Be careful implementing this, because it can be a security issue if you're not cautious.
If a user forgets the method they used to sign up, we'll still return the right user record to your app.
Be careful implementing this, because it can be a security issue if you're not cautious.
That's why I avoid using social login buttons. I have a password manager, so remembering passwords is not a problem. However, remembering if I logged to this site with Facebook, Twitter, Google or something else is.
If users sign up through a social site, their account is still identified by email. So as long as their email addresses are the same between sites, it doesn't matter which social service they use, so they won't have to remember. Twitter doesn't provide an email address, however, so that could be a problem.
yes, you're right about twitter. However, we don't have that much of a problem with people hitting the social login button as much as with people forgetting that they used social last time they logged in.
They then try to enter email and password. When it rejects them, they try to reset the password, and get frustrated that the reset password does not work...
We relatively regularly answer support emails and just tell users "It looks like you used your google account to sign in last time, just hit the right button and you'll get in instantly"
They then try to enter email and password. When it rejects them, they try to reset the password, and get frustrated that the reset password does not work...
We relatively regularly answer support emails and just tell users "It looks like you used your google account to sign in last time, just hit the right button and you'll get in instantly"
Not only that, Facebook's default privacy settings are set up in a way which most users' proper email address is not exposed to sites using social login.
Google logins are the absolute worst, now you have to remember which of your accounts you logged in with (like many others here I have 5 active accounts - I really wish they could give me a single identity that would work with all of them).
If you want a single identity why do you have five active accounts?
I have multiple google accounts because I want separate google identities.
I have multiple google accounts because I want separate google identities.
I have separate google identities because I have a gmail account and my work uses Google Apps; I also have another account that I use for YouTube which I refuse to merge into my gmail account (if that's even possible).
I don't want to merge them together because they're separate accounts for separate purposes, but that's a difficult position to keep because of how absurdly difficult it can be to deal with multiple google accounts. Even though Google supports multiple accounts, their base assumption is that people have exactly one Google account which is exactly one identity which incorporates all of one person.
I've been unable to accept calendar invites sent to my work account because Google Calendar insisted on opening to my personal account when I clicked the link; even if I opened my work calendar using the drop-down, and closed the other window, the link would only open to my personal calendar and then tell me 'you don't have access to this calendar'.
It feels as though the parent poster was asking for Google to understand that one person can have multiple accounts, rather than assuming a 1:1 mapping between the two and behaving as such.
I don't want to merge them together because they're separate accounts for separate purposes, but that's a difficult position to keep because of how absurdly difficult it can be to deal with multiple google accounts. Even though Google supports multiple accounts, their base assumption is that people have exactly one Google account which is exactly one identity which incorporates all of one person.
I've been unable to accept calendar invites sent to my work account because Google Calendar insisted on opening to my personal account when I clicked the link; even if I opened my work calendar using the drop-down, and closed the other window, the link would only open to my personal calendar and then tell me 'you don't have access to this calendar'.
It feels as though the parent poster was asking for Google to understand that one person can have multiple accounts, rather than assuming a 1:1 mapping between the two and behaving as such.
I have one gmail account and 4 different google apps accounts (one so I can have a personalised email that I've had for 15 years, the other 3 are different companies that I'm involved with). I use trello with 3 of those accounts but i only want one login, hence the confusion...
Frankly I would like to have only one login with Gmail which requires triple authentication (password + image or something else + phone or dongle or heartbeat or something), then for everything else just email me a link to log in.
Can you elaborate a little?
Using OAuth is fine and all... but it's not eliminating the customer from having to sign-in still... ie. they are still typing a username and password, just not into your system.
So what are the benefits (both perceived and actual)?
Using OAuth is fine and all... but it's not eliminating the customer from having to sign-in still... ie. they are still typing a username and password, just not into your system.
So what are the benefits (both perceived and actual)?
We have seen a number of customers who improved their overall signup rates by adding OAuth as an option. The effect is even more pronounced on mobile and consumer web.
Most people do not log out of Facebook and Google on their devices, so they do not have to sign-in. They just click "Facebook" then "Approve." That's much easier than filling out your email and password -- particularly on a mobile device.
Most people do not log out of Facebook and Google on their devices, so they do not have to sign-in. They just click "Facebook" then "Approve." That's much easier than filling out your email and password -- particularly on a mobile device.
If they're already logged into Facebook/Twitter, they don't have to type a single thing -- they just hit the "Accept" button and they're done.
Thank you for this comment. I came here just to ask what others experienced. I love these buttons (all hail confirmation bias). It would be great to hear from other peoples experiences whether their users use oauth or not.
It's also true for SaaS. Many of our signups are from Facebook or Linkedin social login. It's one button for the user vs multiple fields.
I can second that. Having interviewed a number of SaaS vendors as part of the customer development work we've been doing at StartHQ (https://starthq.com) it became apparent that some vendors are seeing as many as 60% of their sign ups using Google OAuth.
I think the real takeaway is "Social Login Buttons Aren't Worth It _For B2B_"
Very few people are going to sign up or log into a business account using a personal facebook or twitter account, and few businesses are going to have a lot of people with direct access to their facebook page and twitter feeds.
Very few people are going to sign up or log into a business account using a personal facebook or twitter account, and few businesses are going to have a lot of people with direct access to their facebook page and twitter feeds.
We've found that allowing social logins on our site (ecommerce) only causes confusion for our customers.
"We can't locate your order under that email address. No, not that username either, keep guessing..."
We have found it's best to either not force customers into account creation at all, or make it super easy (ie. a checkbox "yes" and password prompt on the checkout page only).
"We can't locate your order under that email address. No, not that username either, keep guessing..."
We have found it's best to either not force customers into account creation at all, or make it super easy (ie. a checkbox "yes" and password prompt on the checkout page only).
Imagine if linked in or something similarly businessish got into that space.
I have a hotmail account I use for all my professional MS related needs that has become my business social sign-on account. In general, there's room for innovation here. Google really screwed the pooch when they decided Plus Circles were an internal organizational tool instead of a public facade.
I have a hotmail account I use for all my professional MS related needs that has become my business social sign-on account. In general, there's room for innovation here. Google really screwed the pooch when they decided Plus Circles were an internal organizational tool instead of a public facade.
LinkedIn, SalesForce, Amazon, and PayPal are all likely players in the B2B "social" login space.
> Our old login form told users, "Your username or password is incorrect," when they may have the username right, but the password was incorrect. If you have 4 possible usernames and 4 possible passwords, you have 16 possible combinations between them—only one of which is correct. That means in this scenario, the user would have 15 chances to make an error when logging in. But when you know specifically that your username is incorrect, odds of failure drop precipitously.Our old login form told users, "Your username or password is incorrect," when they may have the username right, but the password was incorrect. If you have 4 possible usernames and 4 possible passwords, you have 16 possible combinations between them—only one of which is correct. That means in this scenario, the user would have 15 chances to make an error when logging in. But when you know specifically that your username is incorrect, odds of failure drop precipitously.
This is an old pattern. The reason for it seems to have been forgotten: If you tell the user they got the user name wrong, you're leaking information. They can now try and guess valid account names. Of course, one could argue that this may not matter in their specific case, but it does in some.
The parable of chesterton's fence comes to mind: http://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence
edit: Ah, I really need to overcome that instinct of jumping to the comments whenever I notice something. Looks like they addressed this.
This is an old pattern. The reason for it seems to have been forgotten: If you tell the user they got the user name wrong, you're leaking information. They can now try and guess valid account names. Of course, one could argue that this may not matter in their specific case, but it does in some.
The parable of chesterton's fence comes to mind: http://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence
edit: Ah, I really need to overcome that instinct of jumping to the comments whenever I notice something. Looks like they addressed this.
When you create an account and the username already exists, the website tells you that. How is this difficult for someone to do this instead of guessing the username on the login page? It's the same.
It's more pervasive than just registration too if you allow the username to be adjusted. This is again a problem with email addresses that also allows leakage.
Regarding the probability of attack, people should monitor the number of different usernames attempted by a session/IP not just failed attempts against individual accounts. Otherwise it is very easy to try thousands of username combinations with a selected weak password.
Regarding the probability of attack, people should monitor the number of different usernames attempted by a session/IP not just failed attempts against individual accounts. Otherwise it is very easy to try thousands of username combinations with a selected weak password.
the reason for it is specifically addressed in the article...
"But after some further consideration, we decided that it was a false risk, as the username reminder form already tells you if a username exists"
"But after some further consideration, we decided that it was a false risk, as the username reminder form already tells you if a username exists"
For usernames it might be true but many sites use emails instead of usernames (and rightfully so, it's already complicated for people to remember passwords without forcing them to also remember an unique username).
Emails are more personal and might be easier to link back to personal information. Thus, confirming that there is an associated account with a given email is also a privacy leak, because maybe people don't want to reveal that they have an account on a specific website.
Emails are more personal and might be easier to link back to personal information. Thus, confirming that there is an associated account with a given email is also a privacy leak, because maybe people don't want to reveal that they have an account on a specific website.
But don't you leak the same information during registration? What happens when a user tries to sign up with an already existing email address? Don't you return an error saying that email has already been used?
You could just email them a link to finalize registration. If it has already been used include that information in the email.
This actually argues in favor of only using social logins, which would not leak any clues about other users of the site.
Oh, I wasn't arguing either way. Personally I prefer social login, but I have no strong conviction either way.
email addressess are frequently public information anyway, and often get leaked through other methods like giant CC list emails. Unless you have a specific reason to conceal email addresses, I'd argue that the cost of keeping that tiny nugget of information secret is too high for the level of security it adds.
And as they say in the article, that information is already leaked by the password reset process: "No email by that name available".
And as they say in the article, that information is already leaked by the password reset process: "No email by that name available".
Would the argument then be to change the password reset process to something like, "After we verify that this address exists in our records, a password reset email will be sent to it."
Is the user supposed to sit on their hands, wondering whether the email is still coming? Email is far from instant, especially 'password reset' emails, which I've received hours later in some cases. At what point does the user decide to try another of their email addresses? Or do they just try them all (also painful) and just wait to find out which one return a result? What if the user misspells their own email, a common occurrence? They'll never get an email, and never get an indication that they failed.
Yes, absolutely.
So the risk on that specific page is false then? The risk itself isn't false just because the information is leaked elsewhere..
[deleted]
On why telling users if it is the username or password that is incorrect they say...
<pulls out brute force scripts>
PS. just never let anyone from marketing, design or management discuss your security publicly without review.
But after some further consideration, we decided that it
was a false risk, as the username reminder form already
tells you if a username exists, and is not a significant
security risk for the bajilions of sites that have them.
<pulls out brute force scripts>
PS. just never let anyone from marketing, design or management discuss your security publicly without review.
I have the pleasure of being on the receiving end of a lot of feedback for SaaS and other web development projects, and one piece of feedback we constantly we receive is how much more signups / logins my customers see from adding social sharing buttons.
On a personal level, I use social sharing sign up and login buttons almost 80% of the time in place of regular buttons, and am very OK with doing that from a security perspective personally.
On a personal level, I use social sharing sign up and login buttons almost 80% of the time in place of regular buttons, and am very OK with doing that from a security perspective personally.
So on the positive side, social logins are easier for users, don't require a choice between vague error message or leaking user information, and are probably more secure (likely that Google, Facebook and Twitter have stronger security teams than your company).
On the negative side, social logins contaminate your site with someone else's brand, and take away some of your control (what do you do if Facebook decides to ban the user).
As always, look at your users and their usage and try to make the decision that is best for your site. There is no absolute right or wrong here.
On the negative side, social logins contaminate your site with someone else's brand, and take away some of your control (what do you do if Facebook decides to ban the user).
As always, look at your users and their usage and try to make the decision that is best for your site. There is no absolute right or wrong here.
Here how I read this; "Since social login buttons aren't worth it, it's best to setup a login based on email and manage an email communication with your users instead of social ones. And by the way, Mailchimp may help you with your communication with your customers. Now remove those social buttons and come back to email".
Funnily, I agree with the conclusion and I'm using mailchimp extensively.
Funnily, I agree with the conclusion and I'm using mailchimp extensively.
One key thing I think is to have the email as a username. I know this is generally done anyway these days but as someone who helps maintain a system where users have "usernames" separate to email addresses, there is a high support cost to this. I overhear a lot of support enquiries with "No, enter your username, not your email address! We've emailed you your username".
I think simpler is better and think using email instead of usernames should be what you go for first. However, I do think usernames are useful for public facing profiles in order to keep email addresses private. Another benefit is that usernames are usually shorter to type than email addresses (which is really noticeable on mobile...I should set up a shortcut for mine).
Most sites I've seen accept email or username in the login field. I'm pretty sure that was the default behavior for Django last time I looked into it (years ago).
Most sites I've seen accept email or username in the login field. I'm pretty sure that was the default behavior for Django last time I looked into it (years ago).
I agree with your sentiment personally (email is guaranteed unique, for a start), but as the sysadmin of a company with a sixteen-letter-long domain... it does cause some problems, especially on mobile. Trying to type in a long domain on mobile compounds the problem of also having a long username, which is forced on you by most corporate email address formats, if you have a long name in meatspace.
As a user I strongly agree that I want to know which of my username or password is wrong. While you're at it, please remind me which characters your website allows, and how many are expected.
User/pass guessing by crackers can be solved with passphrases. Don't let registrants get by with a crackable password. Then remind us at the login screen that your site wants a passphrase (you can even flash me something that reminds me of the registration prompt if I forget my passphrase).
User/pass guessing by crackers can be solved with passphrases. Don't let registrants get by with a crackable password. Then remind us at the login screen that your site wants a passphrase (you can even flash me something that reminds me of the registration prompt if I forget my passphrase).
This comes dangerously close to this one:
https://www.portcullis-security.com/security-research-and-do...
Very user-friendly, but not exactly secure. Each bit of information you volunteer to unauthorized user reduces the work the attacker has to do to gain access.
As for "how many expected" - limiting the password length is not exactly a good idea in any case.
Very user-friendly, but not exactly secure. Each bit of information you volunteer to unauthorized user reduces the work the attacker has to do to gain access.
As for "how many expected" - limiting the password length is not exactly a good idea in any case.
I just mean if you do limit the password length or character type, please remind me at the login screen, because there's no way I will remember across sites who wanted 6-8 characters from [aA9$_!#] and who wanted 12-16 from [a9-].
I'd rather just use password manager. Site saying "I have passwords of up to 8 chars" just makes me feel uneasy. Also creates a bigger barrier for fixing it to do the thing right.
Wrong conclusion. There's a difference between bad idea and bad execution.
MailChimp is a business site. Twitter and Facebook are personal mediums. There's a mismatch. As a manager, I wouldn't want my employees using personal mediums for business (I have no control), and conversely, as an employee, I don't want to be logged into Facebook from work, or share my Facebook information with businesses. I would never log in to MailChimp with either of those.
On the other hand, we use Google Apps for Business. I use that as a common login for everything that supports it. Most businesses use Google for business in some form (if nothing else, Google Docs or Youtube or similar), so even if not Google Apps, there's already some integration.
Single sign-on is much more secure than either managing 100 different passwords, or having 100 different businesses managing my password. It's much more convenient. It's just a clear win.
MailChimp is a business site. Twitter and Facebook are personal mediums. There's a mismatch. As a manager, I wouldn't want my employees using personal mediums for business (I have no control), and conversely, as an employee, I don't want to be logged into Facebook from work, or share my Facebook information with businesses. I would never log in to MailChimp with either of those.
On the other hand, we use Google Apps for Business. I use that as a common login for everything that supports it. Most businesses use Google for business in some form (if nothing else, Google Docs or Youtube or similar), so even if not Google Apps, there's already some integration.
Single sign-on is much more secure than either managing 100 different passwords, or having 100 different businesses managing my password. It's much more convenient. It's just a clear win.
To be honest, in this order I hate the login issues:
a) When you can't use an email in the username field.
b) When sites don't tell you which one between username and password is wrong (I don't care what security experts say, I would rather receive more spam, than be constantly frustrated by not knowing which one was wrong in every website I browse once in a blue moon).
c) When the username/password has imposed constraints like (must have lower, upper, number, special character, and the blood of a virgin).
d) When the site doesn't hint you about the username/password constraints that were imposed when you registered.
e) When I don't know which one of my N possible passwords I used (this one is my own fault, and this is the only issue I expect to have).
a) When you can't use an email in the username field.
b) When sites don't tell you which one between username and password is wrong (I don't care what security experts say, I would rather receive more spam, than be constantly frustrated by not knowing which one was wrong in every website I browse once in a blue moon).
c) When the username/password has imposed constraints like (must have lower, upper, number, special character, and the blood of a virgin).
d) When the site doesn't hint you about the username/password constraints that were imposed when you registered.
e) When I don't know which one of my N possible passwords I used (this one is my own fault, and this is the only issue I expect to have).
I'd add:
- when copy/paste is disabled via javascript
- when javascript is required for the form to work
- when copy/paste is disabled via javascript
- when javascript is required for the form to work
With the risk of repeating myself: https://passwordless.net I think we often overdo the simple things such as authentication.
I've looked at implementing an email auth system. My hold back is concern about delivery guarantees, particularly around speed.
For example if I use Mailgun, a reputable service with good infrastructure and a very high rate of delivery. That still doesn't prevent random b.s. around emails not being delivered immediately due to any number of issues. If the user is left waiting for even more than a matter of seconds, they're going to give up / get annoyed.
If I can guarantee instant email delivery, essentially, I'd probably jump to this auth method.
For example if I use Mailgun, a reputable service with good infrastructure and a very high rate of delivery. That still doesn't prevent random b.s. around emails not being delivered immediately due to any number of issues. If the user is left waiting for even more than a matter of seconds, they're going to give up / get annoyed.
If I can guarantee instant email delivery, essentially, I'd probably jump to this auth method.
Good point. My thoughts:
- Email is not the only option to deliver tokens. You could also go for SMS, or both
- For most registrations such emails are anyway commonplace. Combined with long sessions (where possible), I think the risks of delayed emails are low (compared to guys getting frustrated with the password)
- I'm so far happy with Mandrill. But as you say: random b.s. can happen
Random b.s. happens with SMS messages too. I've waited minutes for tokens from my bank's login system on more than one occasion.
Also it's not always the case that a user has access to email when he's trying to log in to your app.
Also it's not always the case that a user has access to email when he's trying to log in to your app.
Yes, stuff happens. But as said: Most services use long-lived sessions. It's a choice: Trouble people with either insecure passwords and password resets, or take the risk that sometimes when a session was closed people might in rare cases not receive their tokens. Looking at my daily browsing I would be more than happy to get rid of most of the passwords.
"Do you want to NASCAR-up your login page?"
I love that comparison.
I love that comparison.
I encountered the "which method did I use to register to this site" problem years ago and I have a simple solution (as a user) to this:
When there are multiple one-click login options, I register with Facebook first, if that's not available or doesn't work, I use Google, then Twitter.
So I don't have to remember which service did I used, just stick to my simple rule and login with Facebook first.
Facebook and twitter may simply be the wrong form of login for a business tool.
That's partly why I'm biased towards Google, since they have fairly neutral associations. People don't usually post anything embaressing to google, and so wouldnt be as threatened with a company wanting access to their Google account.
On the other hand, more options are more distractions. Email and password is so simple and well understood that it just works.
That's partly why I'm biased towards Google, since they have fairly neutral associations. People don't usually post anything embaressing to google, and so wouldnt be as threatened with a company wanting access to their Google account.
On the other hand, more options are more distractions. Email and password is so simple and well understood that it just works.
Also Google has a B2B product suite, so some people might have already a Google account from their company which they can use.
It's old but the point about losing your login, say if Facebook deleted your acount, should not be an issue. If you sign up using Facebook, Facebook gives the requestor your email address. All they have to to is reset their password by email and login using the username and passsword.
Spotify destroyed my account, along with my 4 remaining months of Premium, when I asked to be un-linked from Facebook. YMMV.
What's really annoying is when a site lets you login via social login like HN once did, then removes it, and you have to start all over with a new account. ;/
Original discussion from way back when:
https://news.ycombinator.com/item?id=4603204
https://news.ycombinator.com/item?id=4603204
i personally like having the oauth option. saves me from remembering what username i used with the site, and I dont have to type a username and password since i never sign out.
i set up a pinterest style pig sharing website for fun, and i really enjoyed it when i added the fb login option
i set up a pinterest style pig sharing website for fun, and i really enjoyed it when i added the fb login option
My site, gamerustlers.com, uses just Twitter. It's required to use the site. We use Twitter to communicate when a game is created, and when seats are taken.
Using something other that Twitter makes no sense for us.
Using something other that Twitter makes no sense for us.
This is from 2012, can a mod update the title?
October 2 2012 is a long time ago.
Their findings are just as relevant today, it's just that they're far more relevant for a B2B site than a B2C site.
Their findings are not necessarily any less relevant just because it's from 2012.
In fact -- their findings match almost exactly what my company has discovered.
In fact -- their findings match almost exactly what my company has discovered.
Our analytics show that many people on mobile and consumer websites do indeed want to use OAuth.
(I've been meaning to do a blog post on this topic...)