Hacker News new | ask | show | jobs
by fvargas 2998 days ago
The article shines light on three separate failures on Netflix's part:

1. Canonicalize email addresses

Whether or not dots or +asdf is considered okay, an email address used for identification needs to be canonicalized in order to avoid duplicate sign-ups.

2. Never leak information through sign-up forms

A login attempt either succeeds or fails. That is all the user should know. Telling the user if the attempted email address exists or does not exist is a privacy breach and a security breach as demonstrated in this article.

3. Never assume ownership of an email address until it is verified

Some services verify email addresses at some point in the user flow, some never verify, and few verify at the right point. The best sign-up flow I've seen is Slack where setting a password is part of the email verification flow and a user cannot set a password and own the account until they have verified the email address.

Thus, sending transactional emails beyond verify your email or reset your password before the email address has been verified opens one up to security breaches as in the case of Netflix.

2 comments

Disagree with the first two.

1. Netflix shouldn't have to care about the internal implementation of Gmail addresses. It's perfectly fine to treat ab@service.com and a.b@service.com as separate accounts.

2. If you attempt to sign up for Netflix with an email address which already exists in their system and they tell you that, it isn't a security or privacy breach. There is absolutely no other way to handle the situation.

Agree with the third one though. A "click here to activate" email absolutely needs to be standard in every sign-up flow.

By canonicalization I'm not saying any arbitrary practice by Gmail or any other email provider should be considered as standard. I haven't looked at the RFC in some time, but I don't believe the use of plus suffixes is standard either. Nonetheless, I believe plus suffixes are more commonplace, generally permitted, and serve a reasonable purpose. For instance, sending email to a user using their email address as provided is a good practice in order to preserve a plus suffix which may aid the user in organizing their email. At the same time, canonicalizing email addresses in a sensible way, e.g. stripping plus suffixes, can be an aid for preventing unintentional, duplicate sign-ups. Just consider a sign-up form on the homepage of a website. It's not uncommon for people to enter their email and password into that form by mistake thinking they're signing in. Additionally, if the website compares canonical email addresses when checking login credentials, then a user who signed up with an email address containing a plus suffix can sign in using their base email. These two situations combined could lead to the accidental creation of a duplicate account if canonical email addresses are not compared during registration. There are some trade offs with this strategy, but as long as the canonicalization is implemented reasonably, I see it as an aid to the user. Note that reasonably doesn't necessarily mean stripping dots.

As for the second point, I consider it a privacy breach if a service publicly associates my email address with their service without my consent. Sign-up forms do this when giving different responses when an email address is registered vs not registered.

As for how to handle it, if a user signs up with a new email address, you send them an email to verify their email address and instruct them to check their email. Similarly, if a user attempts to sign up with an already registered email address, you send them an email letting them know they already have an account and instruct them to check their email, which will provide them with a link to login.

In the latter case, if they enter the correct password, you can just directly tell the user they already have an account, as they've proven their identity.

The problem with your canonicalization idea is that it doesn't work in all cases. Yes, it might work with gmail addresses, but there's no way that you can assume that "david+x@example.com" and "david+y@example.com" are actually the same mailbox. If you so assume that, then you've just broken you websites for users where that isn't the case.
Why would you broadly assume an incorrect rule? Email address parsers correctly implement canonicalization rules that consider the domain e.g. gmail. It doesn't require any extra work as a developer and the logic is hidden behind the abstraction. But certainly, you shouldn't go implementing arbitrary rules that aren't reasonably applicable.
> Whether or not dots or +asdf is considered okay, an email address used for identification needs to be canonicalized in order to avoid duplicate sign-ups.

Since it isn't a standard or norm, how would that work? These are gmail exclusive features, and other services have other unique features.