
Social Login Buttons Aren't Worth It (2012) - coryfklein
http://blog.mailchimp.com/social-login-buttons-arent-worth-it/
======
nostromo
This is bad advice for anyone that's not a SaaS company selling to people on
non-mobile browsers, like MailChimp is.

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

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

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

~~~
gingerlime
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"_

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

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

~~~
cratermoon
LinkedIn, SalesForce, Amazon, and PayPal are all likely players in the B2B
"social" login space.

------
makmanalp
> 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](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.

~~~
notatoad
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"

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

~~~
madeofpalk
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?

~~~
ams6110
This actually argues in favor of only using social logins, which would not
leak any clues about other users of the site.

~~~
madeofpalk
Oh, I wasn't arguing either way. Personally I prefer social login, but I have
no strong conviction either way.

------
cyphunk
On why telling users if it is the username or password that is incorrect they
say...

    
    
        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.
    

Oh, damn i didn't realize bajilions of sites do this and yet are so secure.
Next time, a better response i hope: "but instead we decided allow for error
differentiation while also increasing the controls on the number of failed
logins allowed and alerts to security staff in such cases."

<pulls out brute force scripts>

PS. just never let anyone from marketing, design or management discuss your
security publicly without review.

~~~
woah
Yea, it was pretty terrible how they got hacked after this article.

~~~
pureyang
source?

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

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

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

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

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

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

~~~
smsm42
This comes dangerously close to this one: [https://www.portcullis-
security.com/security-research-and-do...](https://www.portcullis-
security.com/security-research-and-downloads/security-
advisories/cve-2014-3445/)

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.

~~~
crasshopper
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-].

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

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

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

~~~
bigbugbag
I'd add:

\- when copy/paste is disabled via javascript

\- when javascript is required for the form to work

------
thesumofall
With the risk of repeating myself:
[https://passwordless.net](https://passwordless.net) I think we often overdo
the simple things such as authentication.

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

~~~
thesumofall
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

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

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

------
brickmort
"Do you want to NASCAR-up your login page?"

I love that comparison.

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

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

~~~
erikb
Also Google has a B2B product suite, so some people might have already a
Google account from their company which they can use.

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

~~~
voltagex_
Spotify destroyed my account, along with my 4 remaining months of Premium,
when I asked to be un-linked from Facebook. YMMV.

------
lnanek2
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.
;/

------
teh_klev
Original discussion from way back when:

[https://news.ycombinator.com/item?id=4603204](https://news.ycombinator.com/item?id=4603204)

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

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

------
kernelcurry
I am sure this has changed since 2012...

~~~
pureyang
It has not.

------
colinbartlett
This is from 2012, can a mod update the title?

------
limsup
October 2 2012 is a long time ago.

~~~
JohnTHaller
Their findings are just as relevant today, it's just that they're far more
relevant for a B2B site than a B2C site.

