1. 35
  1.  

  2. 25

    I fail to see how this is not entirely Netflix’s fault. Every website should be verifying users email addresses. My email server has a catch all account so any email username is valid. Netflix doesn’t need insider info on my server it just needs to stop people signing up using my email addresses by verifying them.

    1. 0

      TFA already includes a rebuttal to this:

      Some would say it’s Netflix’s fault; that Netflix should verify the email address on sign up. But using someone else’s address on signup only cedes control of the account to that person. Others would say that Netflix should disallow the registration of james.hfisher@gmail.com, but this would force Netflix and every other website to have insider knowledge of Gmail’s canonicalization algorithm.

      1. 8

        That’s hardly a rebuttal, it’s poor justification for the bad design. In this case it was a dot, but if I actually make a typo, does that mean some random stranger should have access to my account? Should a website just send spam to any e-mail given? There’s a reason why e-mail verification are a standard. I understand Netflix wants to provide a clean and fast experience, and that’s fine, but they should still wait for verification before sending any sensitive data to the provided e-mail.

        If you think of it, the security breach had very little to do with Gmail. It was Netflix that was about to steal his credit card information, not Gmail.

        1. 1

          The point is that the credit card scam is still present regardless of initial email verification.

          If some average, non-security-conscious Netflix user would fall for the credit card scam by not noticing the last 4 digits of the card, it’s not hard to assume the same user would click through any subsequent validation emails from Netflix. The user might even think it was sent out for extra security, and probably not notice the dot at all.

          If people are adamant on putting the blame on Netflix, the problem wouldn’t be the lack of initial email verification, but rather the ability to change your email at will, after the initial signup. But people would obviously find UX flaws with that restriction.

          In this case it was a dot, but if I actually make a typo, does that mean some random stranger should have access to my account? Should a website just send spam to any e-mail given?

          This argument doesn’t make sense. If you typo your email, and happen to put a scammer’s address, that scammer would happily click “verify” in the verification email that was sent to them. So verification email wouldn’t help you there. Anyway this argument is unrelated to the credit card scam discussed in TFA.

    2. 15

      Given how much confusion is created by systems which do allow “foo.bar” and “foobar” to be different email addresses in the same domain, for different users, Gmail saying “we won’t allow that” is wonderful. Given how often people don’t correctly write down dots or whatever when copying email addresses, Gmail’s behavior is also good for getting the mail to just flow.

      Saying Netflix shouldn’t have to have insider knowledge misses that (1) they made assumptions which required that insider knowledge, and (2) most sites make insider assumptions. Continuing with 2 for now: every site is allowed to have whatever rules they want for the left-hand-side (LHS), and per the standards the left-hand-side is case-sensitive. If I want “bar@” and “bAr@” to be different email addresses, that’s my business. Any email handling system which generally loses case of the LHS is, technically, broken. The federation used by email allows whatever systems are responsible for a given domain to have complete control over the semantics of the LHS.

      In practice, the most widely deployed LHS canonicalization is almost certainly “be case-insensitive”, followed by “have sub-addresses with + or perhaps -”. IMO, the Gmail dot handling is incredibly sane and everyone running mail-systems should seriously consider it.

      If I went out filing bugs against systems which made the case-insensitive assumption, then I’d be dismissed as a crazy person. In practice we (almost) all accept that some assumptions will be made. If you want to be safe, or not have to make assumptions, then validate the email addresses used at signup.

      A friend had some issues with his wife because four different people had signed up for Ashley Madison using his email address (first-name @ gmail.com) and A-M never validated. Perhaps the potential consequences here highlight why not validating email addresses at sign-up or email address change should be interpreted (legally) as reckless negligence. If you’re going to decide that you don’t need to validate, then you assume responsibility for knowing about the canonicalization performed by every recipient domain. So the author of this piece is flat wrong: the moment Netflix decided to not bother validating email addresses, while also using email addresses as authentication identifiers, they assumed complete responsibility for the security consequences of having correct information about canonicalization used in every domain, to keep their authentication identifiers distinct.

      (disclosure: as well as the hat, I’m also a former Gmail SRE, but had nothing to do with this feature)

      1. 1

        Why not just disallow . in email addresses?

        1. 1

          About 40 years too late to decide to start restricting what can be on the LHS. That’s entirely up to the domain. You can have empty strings, SQL injection attacks, path attacks and more, because you can have fairly arbitrary (length-restricted) strings, if you use double-quotes. The LHS without quotes is an optimization for simple cases.

          Given that there exist today domains where the dot matters, and fred.bloggs != fredbloggs, instead those belonging to different people, any site which disallows dots in sign-up will cut off legitimate users.

          Just validate.

      2. 11

        With any provider, the same “scam” technique would work with “+”. The author seems to assume Netflix would know the canonical form of such an address, but “+” doesn’t have to be special. Some providers use “-” instead (free.fr for example). You can use any character you want: in Postfix, this is recipient_delimiter.

        1. 10

          This isn’t a Gmail issue, this is a Netflix issue. I had the same type of email come to an account that I didn’t use for Netflix, and it was a single-click login to someone else’s account. They’re sending a link in plaintext via email that requires no authentication to access your account!

          1. 2

            Is it surprising that access to the associated email address grants access to the account? This is the security model of an awful lot of websites (including the one you’re reading this on) because that’s where password reset links go.

          2. 5

            Wouldn’t this be solved by Netflix simply requiring email confirmation on sign-up (and on email changes)?

            1. 1

              Yes, this blog post is stupid.

            2. [Comment removed by author]

              1. 2

                The chronology is clearly that he got to the page for updating payment information without resetting the password, just by following the link. The password reset was only done later to collect information on “Eve”. So the step 6 as written is correct.

              2. 2

                I agree with the author, this is a Gmail issue, even though I’m surprised Netflix doesn’t confirm email addresses upon sign up.

                1. 2

                  These scams are awful. Netflix probably should be verifying emails before account activation.

                  I have been using my own domain for email for several years now and use a wildcard catch-all *@foo.com. The flexibility is great and I can use unique email addresses for services.

                  1. 1

                    Does netflix even prefill the email input field when one click the update link? In the likely case it doesn’t I fail to see how a scam would even work, implying the user will just fill in its usual credentials and log in in its own account.

                    1. 1

                      Seems pretty weak as a security issue - it isn’t great, but I don’t see any way to monetize a hack/scam like this in a large-scale way.

                      This is also well-served by my standard advice to less sophisticated users that I follow as well - never click on links in emails. If you get an email claiming to be from some service, then go to that service from a bookmark or typed URL, never click the link. Then it’s safe to check on whatever the issue supposedly is.