Hacker News Reader

Comment by Splines | Hacker News Reader

> Hammer the Netflix signup form until you find a gmail.com address which is “already registered”. Let’s say you find the victim jameshfisher.

The bug is right here - you shouldn't be able to determine if a user account already exists.

If an account already exists:

- Logon shouldn't tell you that you have an account and the password was wrong

- Registration should send a "looks like you already have an account" email to the recipient with "maybe this wasn't you" warning, and the web form shouldn't indicate anything out of the ordinary.

- Password reset should say "if an account exists, we just sent it an email"

View on HN

Agree that many steps can be improved. In real live, though, it's not so difficult to guess/find someone who has Netflix, and also find their email. That's a really weak security requirement, security shouldn't depend at all on that part (it seems more relevant for privacy to me)

Further, it is trivial to picture an attack where through some other channel, the attacker already knows the email address of their target, and has the knowledge that this victim has a netflix account.

If I only need these two pieces of information, neither of which is intended to be 'secret', then I might easily already have enough information to attempt this attack on (for example) my ex, or their new partner, or someone at either work or university that I dislike, even if I didn't have enough information to target a random person in another country.

It is good practice not to expose user's email addresses to attackers. It is breathtakingly bad practice to depend on those email addresses being secret.

I really don't see why Netflix needs insider knowledge or whatever to be able to detect john.doe as being the same as johndoe.

I believe it’s because this feature is largely unique to Gmail? So Netflix would need to know and maintain a database of rules based on domains.

* Gmail: Dots are cool.

* Hotmail: No capes! I mean dots. No dots!

* Multiplied by 8 hundred gazillion domains...

You’re thinking too much like a programmer. It’s a single rule for a single domain that accounts for the majority of users.

The right thing to do is ask for a password, but absent that, accounting for gmail addresses seems worthwhile. It would save them getting a thread like this on hn.

No database needed, just ask for e-mail validation by sending an account validation link to the e-mail. Problem mostly solved.

> the web form shouldn't indicate anything out of the ordinary

How will the user know that the registration failed and what to do about it?

Upon entering a valid email (whether it is already registered or not) the form will show the following notification "an email was sent to user@email.com with the sign up instructions, please follow the link in the email to continue the registration" (rewrite for more concise message)

If the user already exists the email will be a warning + a link to the password reset form

If the user does not exist, the email will be a link that confirms the ownership of the email address and the rest of the registration process.

An attacker trying to guess if an email is registered would not know, because the form does not give away that info.

Got it.

Why is it bad to know if an email is already registered?

because if you know someone's email address you have now also discovered that they have an account with a particular service which you should not be able to do.

Furthermore, people reuse passwords. So of course there are a number of known-good login/password combination lists in the wild.

As soon as you find a valid login, you can test all known passwords (plus variations) associated with it.

Can’t you do this anyway on the service? You are assuming there is no rate limiting and the passwords are used directly as bearer tokens to access the site.

But since you are giving advice to the DESIGNER of the site, why not simply tell them not to use passwords? https://qbix.com/blog for example

It's not, necessarily.

It's a tradeoff between usability and security, and each site should make their own decision about what is right for them.

It obviously makes attacks like the one in the article easier, but there are other ways to mitigate that.

An example often given for when revealing an email is registered would definitely be bad is dating website and pornography websites - where identifying someone is a member alone could be embarrassing or compromising.

Outside of such scenarios, websites may decide the increased conversion from a more streamlined registration process and lower numbers of support requests for login issues outweigh the marginal security gains from hiding that information.

And conversion drops right away. On every of my projects as soon as "auto sign in" was dropped -- conversion dropped as well. (assuming that the "conversion" is to make a user to register and do something afterwards)

I know that there should be some kind of compromise since any security measure added to secure accounts will lead to some inconvenience for users.

If your goal to make sign in process as smooth for users as possible you may want introduce as little steps as possible between their landing on a page and "purchase".

But verification of email address should be kind of mandatory and happen before something important will be sent to this email.

Many sites allow you to continue, but limit your account and nag you about verifying your email. This seems like more of a happy medium, if you're concerned about conversion.

Fair warning. That does add a certain level (quite significant) of inconvenience to existing users though. But probably a happy trade-off for most people entrusted with protecting accounts.

> Registration should send a "looks like you already have an account" email to the recipient with "maybe this wasn't you" warning, and the web form shouldn't indicate anything out of the ordinary.

Well that wont work. If you can't register with an email it's obviously because an account has already taken it.

Reply on news.ycombinator.com