7 ms·

I think these are orthogonal issues. The dots do matter, but Netflix should also validate email addresses. However, I don't think it's as critical. Lack of emai

I think these are orthogonal issues. The dots do matter, but Netflix should also validate email addresses. However, I don't think it's as critical. Lack of email validation means I receive someone else's ride details (I agree, annoying), but dots-don't-matter means I might accidentally pay for that person's rides.

lrdd 9y ago
But if just the email validation problem were addressed - you wouldn't accidentally pay for someone's rides. Their account would never be created as they don't have access to the email they provided. Just dealing with email validation solves both problems.
ESRogs 9y ago
If Google fixed dots-don't-matter, couldn't someone still sign up for Netflix with jameshfisher+netflix@gmail.com? If Netflix checks for + address duplicates, then that's not an issue. But you could still have the situation where someone signs up for, let's say, Hulu with your standard jameshfisher@gmail.com account. And then you could still end up paying if you forget whether you ever signed up for Hulu or not (maybe you were about to sign up and didn't, maybe you planned to in the future). Email validation seems like the most important defense against this kind of thing. Dots mattering seems secondary.
- Pxtl 9y ago
  A similar problem exists for weird services like Amazon that allow multiple accounts for the same email address (unless they finally fixed that stupid idea?).
  - mcpherrinm 9y ago
    Multiple accounts with the same email haven't been available for many, many years. I'm not sure exactly when registration for these was disabled, but it was 10+ years ago. Possibly 15-20 years ago. I think it was a valid design decision at the time, before accounts on websites were widespread and a family might only have a single email address from their ISP. The rise of free webmail accounts from Hotmail etc changed that, of course. And now we have a shared understanding of how accounts on websites should work. Neither of those were true in 1994.
    - Pxtl 9y ago
      Good to know. I had accidentally created multiple accounts for myself around '05 or so and was really surprised by it. Iirc back then they also required separate accounts per-country, but I could be wrong about that.
      - stordoff 9y ago
        They still do AFAICT (I had to sign up for a Japanese account relatively recently).
        AnssiH 9y ago
        Amazon Japan and Amazon China are the only ones that have separate accounts from the rest of the Amazon sites.
      - uiri 9y ago
        I don't think they require separate accounts per-country, but my only experience is with .com and .ca. They might do the accounts on a per-realm basis (North America, Far East, Europe, etc.) rather than strictly per-country.
      - tough_luck 9y ago
        I have same account (same mail) with amazon that works across their .com, .in, .fr., .co.uk
    - scrame 9y ago
      Naw, I left about 10 years ago and out was still there, and still had co-workers at a different job asking me about it a couple years later, because they got bit by it. The justification I heard was that someone would have a personal and business (or library) account to the same email, but it definitely persisted longer than you think.
      - mcpherrinm 9y ago
        Well, they were enabled but you couldn't create new ones when I joined 7 years ago. I was under the impression they'd long since been retired at that point. Given the turnover there, ancient lore could have only been a year or two before that. I had to jump through some hoops to get one of the accounts to test something I worked on with them.
  - ams6110 9y ago
    Doesn't seem stupid to me. In the real world can have multiple accounts with a business using the same physical address. Why should contact information be limited to a single account? Why should an email address be assumed to uniquely identify a person? Email sharing is still very common, and many organizations have addresses like info@ or help@ that don't identify anyone at all and could be read by any number of people.
- rowyourboat 9y ago
  Right. The +-suffix suffers from the same problem as the dots-don't-matter-policy: While some implementations use + as a separator between a mailbox name and a suffix, there is nothing in the RFC that encodes that, so different server implementations could just as well see + as a regular letter of the local part. Netflix has no choice but to treat james.h.fisher@gmail.com, jameshfisher@gmail.com and jameshfisher+netflix@gmail com as different email addresses. Really, to the left of the @, almost anything goes, and how an MDA maps the local part to a specific mailbox is completely up to the implementer. As you point out, the only way around this email verification.
bo1024 9y ago
They're both issues, I agree there, but I think Netflix's screwup is larger here. Lack of validation means that Netflix is emailing someone asking them to pay for something, who may be totally different than the person getting that thing.
codetrotter 9y ago
Thinking about this a bit more, I believe that there is another problem with how account creation is done. In general we do it in two steps: 1. User detail and password 2. E-mail confirmation Instead, if we did 1. User details but NOT password 2. E-mail confirmation and subsequently entering the password on the page that was sent via e-mail. Actually, I think the most optimal would be 1. Enter e-mail address only 2. E-mail confirmation and entering all details This would simultaneously protect the person that initated account creation and the owner of the e-mail address from one-another.
- batuhanw 9y ago
  Second solution seems pretty optimal for security but not sure if users up for that.
- DougWebb 9y ago
  Typically when I implement user self-registration for my portal-website clients, I use a variation of your third option: 1. Enter email address and some out-of-band information that only an existing-account-holder should know. Eg: a web portal for a utility company could ask for the account number and amount due from a recent bill. 2. Send confirmation email with a code/link. 3. After user enters a valid code, continue registration by gathering additional user details, password, and (usually) recovery Q&A. The user account is not created until step 3; if they provide a fake email, it's as if the registration attempt never occurred. Absolutely no access is granted until after the final step. The extra details in step #1 only works for website registration of a user that has a pre-existing relationship with the company, of course. For a new account, email address is all you should request at that point.
  - stephen_g 9y ago
    I wish requiring validation was still the norm. I get that services and sites want to reduce “friction” and get people using it right away, but anybody like me with fairly generic gmail address knows, many people don’t know their own email address. I must have hundreds of active accounts linked to that email that I didn’t sign up for (although I’m sure a lot of them can’t be logged into anymore and the people can’t recover their passwords). That account became unusable, I got my own domain account a decade or so ago to replace it but still look in there occasionally. Please though, anybody implementing signups - if you are going to let people sign up without validating email addresses, put a “I didn’t sign up for this account” link in every email you send.
nabla9 9y ago
Dot's don't matter if the relevant RFC says they don't matter and I think this is the case. Google follows the standard, Netflix does not.
- B1FF_PSUVM 9y ago
  The other way around. It's Google who decided to do it that way.
  - cestith 9y ago
    Which the RFCs for email do allow. The local part is the local part, under local control, and should not be assumed about by remote systems.
    - B1FF_PSUVM 9y ago
      Regular people, upon looking at an email address, might think that - alert@example.com - A.Lert@example.com - Al.Ert@example.com etc. were different. Requiring them to know or check what's the "local control" policy at each site may be a stretch. Principle of least surprise, etc.
      - nybble41 9y ago
        These are all different e-mail addresses; that part should not be surprising, and Netflix is absolutely doing the right thing by considering them different. (The same goes for "+labels": a "+" is a perfectly valid character in the local part of an e-mail address and the meaning of the "+" is entirely up to the mail host, so e.g. rejecting e-mails with a "+" or stripping out the "+" and following characters would violate the RFCs.) No, Netflix's errors lie in (a) sending e-mail for any purpose other than account validation to an unvalidated e-mail address, and (b) including a pre-authenticated link in the e-mail that bypasses the normal account access controls. Pre-authenticated links are poor security practice in general; e-mail is notoriously insecure, and simply being able to read an e-mail sent to the address on file does not imply that the reader should have access to the account. As for "dots don't matter", it can be argued that Google made some scams a bit easier by routing e-mails to non-canonical e-mail addresses to users who don't realize they even have such addresses; my own recommendation would have been to block registration of e-mails differing only in the number or placement of dots, but bounce any incoming mail where the "To:" field doesn't match the canonical form chosen at account creation time. However, since doing away with the "dots don't matter" policy would not significantly impact the more general issue of e-mail address aliasing, I do not believe that Google's policies are to blame for this particular security gap.
emn13 9y ago
dots-don't-matter isn't sufficient to fix this issue - any other canonicalization issues would surfacea as the same problem. That might include casing, unicode issues, the `+irrelevantsuffix` stuff, and probably more, including perhaps any kind of aliases in the hostname. The idea that you can tell whether two accounts are the same is questionable; netflix should not be relying on it. Furthermore, the hack is possibly much less serious (but nonetheless conceivable) even without any canonicalization issues whatsoever. Apparently, a user can trick netflix into sending email to arbitrary email addresses. Sure, this is likely not to be an issue if the recipient doesn't have netflix in the first place - but if you try 1000 times (which spammers and phishers are wont to do) - you may well happen to hit a person that'll pay nonetheless - perhaps they forgot which email they used for netflix in the first place, or perhaps they share an email account, or perhaps the real owner is dead/on vacation/otherwise unavailable and somebody else is tending the account and thus more gullible than usual. Netflix should never ask for money from random strangers without making 100% clear what the context of that request is. (If indeed this article is accurate, because I wouldn't rule out the chance that the author made some oversight earlier).

lrdd 9y ago

But if just the email validation problem were addressed - you wouldn't accidentally pay for someone's rides. Their account would never be created as they don't have access to the email they provided. Just dealing with email validation solves both problems.

ESRogs 9y ago

If Google fixed dots-don't-matter, couldn't someone still sign up for Netflix with jameshfisher+netflix@gmail.com? If Netflix checks for + address duplicates, then that's not an issue. But you could still have the situation where someone signs up for, let's say, Hulu with your standard jameshfisher@gmail.com account. And then you could still end up paying if you forget whether you ever signed up for Hulu or not (maybe you were about to sign up and didn't, maybe you planned to in the future). Email validation seems like the most important defense against this kind of thing. Dots mattering seems secondary.

Pxtl 9y ago
A similar problem exists for weird services like Amazon that allow multiple accounts for the same email address (unless they finally fixed that stupid idea?).
- mcpherrinm 9y ago
  Multiple accounts with the same email haven't been available for many, many years. I'm not sure exactly when registration for these was disabled, but it was 10+ years ago. Possibly 15-20 years ago. I think it was a valid design decision at the time, before accounts on websites were widespread and a family might only have a single email address from their ISP. The rise of free webmail accounts from Hotmail etc changed that, of course. And now we have a shared understanding of how accounts on websites should work. Neither of those were true in 1994.
  - Pxtl 9y ago
    Good to know. I had accidentally created multiple accounts for myself around '05 or so and was really surprised by it. Iirc back then they also required separate accounts per-country, but I could be wrong about that.
    - stordoff 9y ago
      They still do AFAICT (I had to sign up for a Japanese account relatively recently).
      - AnssiH 9y ago
        Amazon Japan and Amazon China are the only ones that have separate accounts from the rest of the Amazon sites.
    - uiri 9y ago
      I don't think they require separate accounts per-country, but my only experience is with .com and .ca. They might do the accounts on a per-realm basis (North America, Far East, Europe, etc.) rather than strictly per-country.
    - tough_luck 9y ago
      I have same account (same mail) with amazon that works across their .com, .in, .fr., .co.uk
  - scrame 9y ago
    Naw, I left about 10 years ago and out was still there, and still had co-workers at a different job asking me about it a couple years later, because they got bit by it. The justification I heard was that someone would have a personal and business (or library) account to the same email, but it definitely persisted longer than you think.
    - mcpherrinm 9y ago
      Well, they were enabled but you couldn't create new ones when I joined 7 years ago. I was under the impression they'd long since been retired at that point. Given the turnover there, ancient lore could have only been a year or two before that. I had to jump through some hoops to get one of the accounts to test something I worked on with them.
- ams6110 9y ago
  Doesn't seem stupid to me. In the real world can have multiple accounts with a business using the same physical address. Why should contact information be limited to a single account? Why should an email address be assumed to uniquely identify a person? Email sharing is still very common, and many organizations have addresses like info@ or help@ that don't identify anyone at all and could be read by any number of people.
rowyourboat 9y ago
Right. The +-suffix suffers from the same problem as the dots-don't-matter-policy: While some implementations use + as a separator between a mailbox name and a suffix, there is nothing in the RFC that encodes that, so different server implementations could just as well see + as a regular letter of the local part. Netflix has no choice but to treat james.h.fisher@gmail.com, jameshfisher@gmail.com and jameshfisher+netflix@gmail com as different email addresses. Really, to the left of the @, almost anything goes, and how an MDA maps the local part to a specific mailbox is completely up to the implementer. As you point out, the only way around this email verification.

bo1024 9y ago

They're both issues, I agree there, but I think Netflix's screwup is larger here. Lack of validation means that Netflix is emailing someone asking them to pay for something, who may be totally different than the person getting that thing.

codetrotter 9y ago

Thinking about this a bit more, I believe that there is another problem with how account creation is done. In general we do it in two steps: 1. User detail and password 2. E-mail confirmation Instead, if we did 1. User details but NOT password 2. E-mail confirmation and subsequently entering the password on the page that was sent via e-mail. Actually, I think the most optimal would be 1. Enter e-mail address only 2. E-mail confirmation and entering all details This would simultaneously protect the person that initated account creation and the owner of the e-mail address from one-another.

batuhanw 9y ago
Second solution seems pretty optimal for security but not sure if users up for that.
DougWebb 9y ago
Typically when I implement user self-registration for my portal-website clients, I use a variation of your third option: 1. Enter email address and some out-of-band information that only an existing-account-holder should know. Eg: a web portal for a utility company could ask for the account number and amount due from a recent bill. 2. Send confirmation email with a code/link. 3. After user enters a valid code, continue registration by gathering additional user details, password, and (usually) recovery Q&A. The user account is not created until step 3; if they provide a fake email, it's as if the registration attempt never occurred. Absolutely no access is granted until after the final step. The extra details in step #1 only works for website registration of a user that has a pre-existing relationship with the company, of course. For a new account, email address is all you should request at that point.
- stephen_g 9y ago
  I wish requiring validation was still the norm. I get that services and sites want to reduce “friction” and get people using it right away, but anybody like me with fairly generic gmail address knows, many people don’t know their own email address. I must have hundreds of active accounts linked to that email that I didn’t sign up for (although I’m sure a lot of them can’t be logged into anymore and the people can’t recover their passwords). That account became unusable, I got my own domain account a decade or so ago to replace it but still look in there occasionally. Please though, anybody implementing signups - if you are going to let people sign up without validating email addresses, put a “I didn’t sign up for this account” link in every email you send.

nabla9 9y ago

Dot's don't matter if the relevant RFC says they don't matter and I think this is the case. Google follows the standard, Netflix does not.

B1FF_PSUVM 9y ago
The other way around. It's Google who decided to do it that way.
- cestith 9y ago
  Which the RFCs for email do allow. The local part is the local part, under local control, and should not be assumed about by remote systems.
  - B1FF_PSUVM 9y ago
    Regular people, upon looking at an email address, might think that - alert@example.com - A.Lert@example.com - Al.Ert@example.com etc. were different. Requiring them to know or check what's the "local control" policy at each site may be a stretch. Principle of least surprise, etc.
    - nybble41 9y ago
      These are all different e-mail addresses; that part should not be surprising, and Netflix is absolutely doing the right thing by considering them different. (The same goes for "+labels": a "+" is a perfectly valid character in the local part of an e-mail address and the meaning of the "+" is entirely up to the mail host, so e.g. rejecting e-mails with a "+" or stripping out the "+" and following characters would violate the RFCs.) No, Netflix's errors lie in (a) sending e-mail for any purpose other than account validation to an unvalidated e-mail address, and (b) including a pre-authenticated link in the e-mail that bypasses the normal account access controls. Pre-authenticated links are poor security practice in general; e-mail is notoriously insecure, and simply being able to read an e-mail sent to the address on file does not imply that the reader should have access to the account. As for "dots don't matter", it can be argued that Google made some scams a bit easier by routing e-mails to non-canonical e-mail addresses to users who don't realize they even have such addresses; my own recommendation would have been to block registration of e-mails differing only in the number or placement of dots, but bounce any incoming mail where the "To:" field doesn't match the canonical form chosen at account creation time. However, since doing away with the "dots don't matter" policy would not significantly impact the more general issue of e-mail address aliasing, I do not believe that Google's policies are to blame for this particular security gap.

emn13 9y ago

dots-don't-matter isn't sufficient to fix this issue - any other canonicalization issues would surfacea as the same problem. That might include casing, unicode issues, the `+irrelevantsuffix` stuff, and probably more, including perhaps any kind of aliases in the hostname. The idea that you can tell whether two accounts are the same is questionable; netflix should not be relying on it. Furthermore, the hack is possibly much less serious (but nonetheless conceivable) even without any canonicalization issues whatsoever. Apparently, a user can trick netflix into sending email to arbitrary email addresses. Sure, this is likely not to be an issue if the recipient doesn't have netflix in the first place - but if you try 1000 times (which spammers and phishers are wont to do) - you may well happen to hit a person that'll pay nonetheless - perhaps they forgot which email they used for netflix in the first place, or perhaps they share an email account, or perhaps the real owner is dead/on vacation/otherwise unavailable and somebody else is tending the account and thus more gullible than usual. Netflix should never ask for money from random strangers without making 100% clear what the context of that request is. (If indeed this article is accurate, because I wouldn't rule out the chance that the author made some oversight earlier).