Social Login Buttons Aren't Worth It (2012) • Hacker News Board

Re: Social Login Buttons Aren't Worth It (2012)

#71

Post by Rapzid » Wed, Jul 02, 2014, 4:11 PM UTC

notatoad wrote: post #19

makmanalp wrote: post #7

> 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 use…

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"

So the risk on that specific page is false then? The risk itself isn't false just because the information is leaked elsewhere..

Re: Social Login Buttons Aren't Worth It (2012)

#72

Post by Rapzid » Wed, Jul 02, 2014, 4:15 PM UTC

GrinningFool wrote: post #65

vacri wrote: post #61

Earlier quoted context omitted.

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…

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

Yes, absolutely.

Re: Social Login Buttons Aren't Worth It (2012)

#73

Post by Rapzid » Wed, Jul 02, 2014, 4:18 PM UTC

madeofpalk wrote: post #40

giovannibajo1 wrote: post #24

Earlier quoted context omitted.

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…

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.

Re: Social Login Buttons Aren't Worth It (2012)

#74

Post by gingerlime » Wed, Jul 02, 2014, 6:38 PM UTC

finkin1 wrote: post #54

gingerlime wrote: post #29

Earlier quoted context omitted.

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 i…

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"

Re: Social Login Buttons Aren't Worth It (2012)

#75

Post by smsm42 » Wed, Jul 02, 2014, 9:52 PM UTC

crasshopper wrote: post #69

smsm42 wrote: post #33

Earlier quoted context omitted.

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.

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.

Re: Social Login Buttons Aren't Worth It (2012)

#76

Post by vacri » Wed, Jul 02, 2014, 10:21 PM UTC

GrinningFool wrote: post #65

vacri wrote: post #61

Earlier quoted context omitted.

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…

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.