5 ms·

Absolutely - his proposed solution - disabling the dots-dont-matter feature and retiring them does nothing to stop this exact same attack vector instead employi

by pryce 9y ago

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.

kevin_thibedeau 9y ago
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.
- jdhawk 9y ago
  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.
  - adarshaj 9y ago
    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
- danjayh 9y ago
  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.
- dkersten 9y ago
  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.
  - sedm0784 8y ago
    > 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 https://www.dropbox.com/s/t213wkajdz5753k/yahoolies.png?dl=0
ThoAppelsin 9y ago
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 https://tools.ietf.org/html/rfc5233
- Franciscouzo 9y ago
  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.
  - homero 9y ago
    Yeah I do it all the time
- __david__ 9y ago
  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.
- drdaeman 9y ago
  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.
Splines 9y ago
> 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"
- sankalp_sans 9y ago
  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.
- slx26 9y ago
  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)
  - pryce 9y ago
    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.
    - 9y ago
twhb 9y ago
The difference is that the dot behavior is non-standard, the plus behavior is standard.
- pryce 9y ago
  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 https://tools.ietf.org/html/rfc5322#section-3.2.3
gilbetron 9y ago
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.

by pryce 9y ago

kevin_thibedeau 9y ago

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.

jdhawk 9y ago
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.
- adarshaj 9y ago
  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
danjayh 9y ago
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.
dkersten 9y ago
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.
- sedm0784 8y ago
  > 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 https://www.dropbox.com/s/t213wkajdz5753k/yahoolies.png?dl=0

ThoAppelsin 9y ago

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 https://tools.ietf.org/html/rfc5233

Franciscouzo 9y ago
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.
- homero 9y ago
  Yeah I do it all the time
__david__ 9y ago
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.
drdaeman 9y ago
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.

Splines 9y ago

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

sankalp_sans 9y ago
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.
slx26 9y ago
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)
- pryce 9y ago
  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.
  - 9y ago

twhb 9y ago

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

pryce 9y ago
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 https://tools.ietf.org/html/rfc5322#section-3.2.3

gilbetron 9y ago

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.