Comment by pryce | Hacker News Reader

Comment by pryce | Hacker News Reader

Parent Full thread

Absolutely - his proposed solution - disabling the dots-dont-matter feature and retiring them does nothing to stop this exact same attack vector instead employing the '+' feature that he admires and wishes to retain.

The attack goes like this:

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

* Eve creates a Netflix account with address jameshfisher+netflix

* Sign up for free trial with a throwaway card number.

* After Netflix applies the “active card check”, Eve cancels the card.

* Wait for Netflix to bill the cancelled card. Then Netflix emails jameshfisher+netflix, going to jameshfisher's inbox, asking for a valid card.

* Hope Jim reads the email to jameshfisher+netflix, assumes it’s for his Netflix account backed by jameshfisher, then (follows a link in the email and) enters his card 1234.

* Eve changes the email for the Netflix account to eve@gmail.com, kicking Jim’s access to this account.

* Use Netflix free forever with Jim’s card 1234!

Either they're both security liabilities, and they should both be removed, or the problem lies elsewhere.

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

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.

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.

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

Moreover some broken email validators reject plus addresses. It's nice to be able to fall back on special dot combos when you want to keep track of sites selling your email to spammers.

Spammers already know the dot rules. Its fairly easy to identify a Domain Group (ymail/yahoo) or (google/gmail/somewhere.edu) and then strip and reapply certain rules based on what that Mail Provider allows.

That's true in theory. In practice however, I've had success with figuring out a service that leaked my dotted address (I used a dot because the service didn't validate email with plus). I think this is often the case too because, spammers don't really bother validating emails by postprocessing etc. and just sell the emails in bulk in shady markets

Thank you.. I use this feature in exactly the same way. As I read,I was sitting there thinking "I can't possibly be the only one who knows about,uses,and likes this feature". Disabling it at this point would seriously screw up my life. It also prevents people from registering all of those close variations of my gmail address, which I also like.

I used to use + for that purpose and was always pretty annoyed when a website wouldn’t accept it. I’ve since dropped gmail for fastmail though so now I use sitename@sites.mydomain for all website registrations. No site ever rejects it and it works great for knowing where spam comes from, although I’ve had some funny phone calls where people were baffled that my email address starts with their website name.

> No site ever rejects it

Have you ever tried it on Yahoo? They wouldn't let me set my email address to yahoo@mydomain a few years ago, claiming that the "email owner" had blocked this: https://www.dropbox.com/s/t213wkajdz5753k/yahoolies.png?dl=0

Perhaps Netflix people are to blame for taking +tagged mail addresses as different than the ones that are not tagged. It is a well-acknowledged [1] and commonly offered feature by the email providers that should have been accounted for.

Dots-don't-matter, on the other hand, is very specific to Google, and they simply do matter in many other (if not all other) email providers. I think Netflix shouldn't be blamed for not accounting for provider-specific, non-standard equivalences.

Email address verification alone doesn't seem to fix all the erroneous aspects of this issue: Let's say Netflix was requesting verification, and then you receive the email for the +tagged mail address. Shouldn't it say that you already own a Netflix account, instead of asking for a verification at that point?

[1] https://tools.ietf.org/html/rfc5233

I'd hate it if websites started implementing that, I like being able to register to the same site with the same email multiple times.

Yeah I do it all the time

The + thing is common but is absolutely not universal. I can alias individual + emails on my system just fine (which means that x+a@example.com and x+b@example.com are not equivalent) and most smtp servers allow you to set an alternate character (I set it to '.' and '_' so x.a@example.com and x_b@example.com are aliased together).

In short, Netflix cannot assume things after the '+' are irrelevant and Netflix absolutely cannot canonicalize random emails like that.

All of this would be still useless regarding the proposed attack concept, because eve@gmail.com is also eve@googlemail.com.

And domain aliasing is certainly out of scope of any email RFCs I saw. Netflix (and everyone else) may know about googlemail.com, but it's virtually impossible to know about all other cases.

I don't understand - won't this process fail when the person signs up for "jameshfisher+netflix@gmail.com"? Netflix will send a confirmation email to the real jameshfisher@gmail.com, and not confirm it, and so Netflix won't create the account. Things stop at this point.

The difference is that the dot behavior is non-standard, the plus behavior is standard.

That's incorrect. The validity of accepting the '+' character as part of an email address is part of the standard (-though it is a standard ignored by many prominent websites, aliexpress is just one example I believe)

The acceptibility of the '+' character is specified in RFC 5322 [1].

However, the behaviour where an address comprised of:

local-part "+" some-suffix "@" domain

is automatically routed to the address: local-part "@" domain

it certainly not part of the standard. I find it very useful myself and would be displeased to see that functionality removed, yet this is certainly not part of the standard.

[1] https://tools.ietf.org/html/rfc5322#section-3.2.3

Reply on news.ycombinator.com