On a tangentially related note, developers, please remember that not everybody in the universe has a Twitter account, or wants one. If you have some cool product and I must sign in with FB/Twitter, straight to the close tab button I go and I'm not looking back.
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)
Actually, I'm quite happy to see 'shitty grocery apps' outsourcing authentication, since it means they don't have a database full of plaintext passwords.
When Spotify launched in the US, they disabled signups through their in-house authentication system and required that new accounts be created through the Facebook login. I never quite understood this, since I have a strong aversion to paying actual money for anything associated with my facebook account.. Thankfully they kept the old login system around for existing users (and they've since re-enabled sign-ups through it.)
They were heavily pushing the social streaming aspect, and admitted to as much. Letting other people know who you are listening to is a longstanding tradition, and worth good money to Spotify (who never raked it in to begin with).
I get that, but between the opt-out popups trying to trick you into broadcasting stuff on facebook and disabling signups for the old login system it got to be a bit much.
While I agree it's dumb to only provide a FB/Twitter login, you should also keep in mind that I am much more comfortable with logging in on Twitter, mostly because most things I post or do on Twitter are implicitly meant for public consumption (ignoring things like DMs, which feel like afterthoughts).
Facebook gives the option to the users not to give some permissions. i.e. in theory an app is not allowed to require some extended permissions such as post on your timeline etc. Of course in practice I've seen apps that won't let you continue unless you give them all permissions they asked for - which is against the rules Facebook set in place.
I agree with the conclusion, but the even more wildly actionable information is that you can decrease CS costs and increase customer happiness by using copywriting better than "That email and password do not match our records." (Also, as a product owner with an engineering background, I have to come down on the "In this case, prefer UX over security" side of the debate, since there are numerous other options for divining existence of an account/email address and refusing to tell the account owner that gets you no marginal security benefit but does frustrate their use of your system.)
The thing I find pretty hilarious (sad?) is that many sites that give you the generic "username or password is wrong" message are perfectly happy to tell you that a username is in use if you try to sign up for a new account (geez, I guess they sort of have to!).
Thanks, that's hilarious. I can see someone thinking that unique passwords are a way to make sure that people aren't overusing common passwords - and not realizing that you are implicitly letting everyone know what passwords are currently in use.
Guild Wars 2 is like this. I was trying to use the same password for two accounts and received “Unavailable password. You or someone else has used it before."
I think using an email address (and/or a uniquely generated username), as an identifier is the best comprimise. Then a generic 'credentials invalid' => retrieve your account: 'enter email' page to reset passwords. And require a confirmation click from your email for two step sign up.
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.
I'd suggest that your last point is providing a bad user experience in the interests of privacy. Many people (myself included) use these forms because we've forgotten our password or at worst forgotten the email we used to sign up. I have about 5 different email addresses I use for various things so I'd be quite disappointed to see a thank you message if it wasn't the email I had actually used to register. There's also the use-case where people mistype their email address.
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.
The title is total linkbait -- once you read through the article, it becomes clear that all the author is claiming is that social login buttons weren't the right choice for Mailchimp. They might be the right choice for others though: "Sometimes it makes a lot of sense, and other times it’s just not worth the trade-offs".
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.
People seemed to miss this article when it was posted here when it was published. Surprised at some of the comments; they seemed to only read the headline before commenting as well.
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.
> What if Facebook or Twitter were hacked? Your social profile would be at risk (the sun would still rise tomorrow), but so would any other account on other services that are connected. That’s a little scary. Yes, Facebook and Twitter are good at security, but nobody, NOBODY, is perfect. Social login buttons delegate control of your users’ credentials to another service, rather than ensuring security yourself.
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.
This is doubly true when it comes to Mozilla's Persona. I implicitly trust my email provider more than any other site's login system (at least, the ones that email password resets), so why not delegate to that all the time instead of insisting on a different username and password?
Man, I'm glad to read some anti-social login stuff, as I personally do not like everyone depending on FB. I've read articles on tech crunch which say to ONLY have facebook logins for MVP, which made me cringe.
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)
Exactly. Mailchimp has a very specific userbase, probably much closer to Basecamp than Facebook. If you're in that camp (serving ads, tracking biz finances, time tracking for freelancers, etc.) then Facebook/Twitter login may send the wrong message, that you're fluff. But, if you are fluff (music sharing, video game discussion, daily joke email) then social login could be very compelling to your potential users.
> Social login buttons delegate control of your users’ credentials to another service, rather than ensuring security yourself.
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.
> Does mailchimp.com? I doubt it (but I'd be impressed if they do).
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/
We use Mozilla Persona and would argue we get the benefit of a secure system without the detriment of forcing a user to be a member of a social network when they may not wish to be.
It's certainly possible that they may be more secure than a lot of smaller sites, although that's not guaranteed - social media sites are fairly likely to be more interested in agility than robust security.
What is pretty much guaranteed is that there's more people trying to hack Facebook/Twitter security than most smaller sites.
> 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.
For services I want to quickly try out once, if you just need a quick way to authenticate, I will look for a Facebook login button and generally leave the site if it doesn't have one.
Of course you also can't ask for any odd permissions either!
Did they consider that people tend to not use their facebook account for work accounts?
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.
I was thinking this the entire time I was reading the article, and was disappointed not to see it mentioned. Persona was invented precisely to solve this problem.
> If you’re using Twitter and Facebook for signup too you’ve got a bigger problem. A user’s credentials are then bound to another account on another service that could be canceled at any time, breaking access to your app without the user knowing
I'd never really thought about this. What do people suggest doing to handle this sort of use case?
While I agree (mostly) with the conclusions of the article, the reason social login buttons exist, is that people want easy access to services without having to fill out a bunch of stuff. Services like social login, persona and other open id are a step in the right direction for solving that, but I think it would be best if it were implemented in the browser. Specify how you'd like to identify yourself to the web (or specific pages) and just add 1-click confirmations. Can't believe I'm saying this, but Microsoft's InfoCard would have been perfect for this :)
Even though I very much prefer having an FB login, and think that is much more secure than having manual login (and thus having to remember passwords, which most people will "solve" by the having the same password, which is really insecure),for the love of god, keep your social logins down to 1-2 options, if you must have them. Please do not throw in Facebook, Twitter, GitHub, Google, LinkedIn, and the rest of the kitchen sink.
It should be noted that MailChimp is huge. I have no figures, but I'm guessing they have millions of users. This means that problems that affect 0.1% of their userbase still represent a nominally large number of users. They don't have problems like user acquisition and brand recognition.
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.
> "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"
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.
Looking at the MailChimp site, I don't understand how that would make much of a difference. Right now, you can enter emails into the "Forgot Username" field and eventually hit a good one, but then you need to crack the email account to get the username so that you can then stick that in the "Forgot Password" form. Eliminating usernames, you click the "Forgot Password" link and enter emails into the field until you hit a good one, giving you both the email and "username" right away.
I'll keep conveniently logging into a lot of services with social logins, thank you.
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.
But telling the user that their username OR password is incorrect is good practice though right? If you were trying to break in to somebody's account, it would be better for the person breaking in to not know whether or not that account exists, is a typo etc.
Is it really "good practice"? It seems like cargo-cult security to me. Usernames are usually public anyway; refusing to reveal the existence of a user name as part of the login process but revealing it elsewhere in your application is pointless.
Its an interpretation of the guidance that comes from the NIST 800 series of publications about information security.
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?
Take it to the extreme and think about banking. You wouldn't want to have a system where you confirm and deny the existence of accounts for somebody who's rotating through a brute force. SSH logins for instance do this.
But if usernames are released publicly in forums, google crawled pages etc, then an attacker already knows the existence of a subset of the accounts at least.
For example, somebody attacking HN can crawl pages such as this one and determine that 'skeletonjelly' is a valid HN user.
Sure, but I guess there's no one single security model that fits all situations. I guess that's what I meant by "best practice". Obviously internet banking usernames wouldn't be listed somewhere public
It's addressed in the article. It's a valid concern, but they explain their decision - their "forgotten username" screen is a pretty simple way to check whether a username exists or not, so it's almost a moot point as far as security is concerned.
Depends on your target audience imo. For a consumer facing product, If a considerable size of your traffic is coming from facebook, it sure makes sense to have that option.
