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.
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.
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.
I had to jump through some hoops to get one of the accounts to test something I worked on with them.
As you point out, the only way around this email verification.
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.
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.
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.
As a user, I cannot trust that a website gets the recovery flow right. Some websites will allow you to bypass email and password if you know the answer to the question. Because of that, I cannot put in the real answer, as that would be a massive security risk.
So I usually put in some random garbage, which means it's essentially a second password. Well, if I lost my first password, chances are good that I lost the second password as well.
So please, don't do security questions. Just send a password reset link by email.
If you're worried about stuff like payment info stored in the account, just ask me to re-enter those details after I changed my password.
1. User must enter their email address, and I send them an email with a recovery code.
2. After they enter the code, validating control of the email address, I show them the Question they chose and let them enter the answer.
3. After they enter the correct answer, I force them to update their password, and I send a confirmation email about the password update.
The emails all provide contact information and ask the user to get in touch if they didn't initiate any of these actions.
You're right about the answer being essentially a second password, and I treat it as such: only an encrypted hash is stored, type=password fields are used to enter it.
One of my clients did request getting rid of the Q&A, which I was able to do pretty easily because email verification step and reset code were already implemented.
On a personal note, I never use real answers for security questions. I use randomly generated strings, just like my passwords. If I can choose my own question I use a random string for that too.
The possible disadvantage I see with the third option however is that if you are at a service desk, and they are trying to sign you up for a membership of some sort, they can't complete your registration on the spot. You would have to go home and use the computer to complete your registration (unless you can use email client on your smartphone). Which means they may lose a possible member if they don't ensure that you finish the registration right there and then.
For that reason it may be better to collect the email address, all customer details, and the desired password (typed twice). Then when the confirmation link is sent, the confirmation link should take you to a link that asks you for your password again (once) before your account is validated. This ensures that the person at the service desk is really the person using the email account to do the validation. Mere access to the email account should not be enough. The main advantage here is to make sure as little work as possible is left to the customer to do by himself when he gets home. I agree that this is a lot more messy than Doug Webb's approach, because the only accounts in that approach are validated accounts.
However to the extent that one does not want to lose a possible new membership because someone went home and decided not to continue the process because it is a lot of work, it may be worth it.
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).
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.
Google follows the standard, Netflix does not.
- 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.
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.
On some systems, anything ending in '@example.com' may be a single account.
It may be that defined address to account mappings exist on a domain and all other addresses map to a default account. It's common enough the hosting industry supports it and it has a name - a catchall email account.
Nobody sending mail to any of those addresses needs to know how many addresses map to the account associated with the address to which they are sending. It's an address, not an identifier. I would argue you don't have a reason nor a right to know the address to account mappings in my systems.
What a sender should reasonably expect is that someone who can receive mail delivered to a particular address is in charge of the email account to which that address maps. Sending a verification email to someone expecting to receive it is the way to validate the recipient is the intended recipient. That's it.
If I give you my phone number, do you need to know what other phone numbers will ring that phone or how many phones I answer in order to call me? Do I need to disclose all the possible places I might receive a package if I want one delivered to a single place? No.
Email addresses are addresses. That's all they are. Stop pretending they are something else, and this will become much clearer for you.
The RFC also notes that the local-part MAY be case-sensitive (i.e. it's up to the host).
Edit: the host SHOULD ignore case: "a host that expects to receive mail SHOULD avoid defining mailboxes where [...] Local-part is case-sensitive".
(Similarly, although the RFC does say hosts shouldn't have case-sensitive local-parts, it doesn't say that senders can assume that local-parts are case-insensitive.)
But I also see his point about how this can confuse users who don't realize this or are not using this behavior intentionally.
They absolutely could. Netflix can't assume they are or they aren't. Which means Netflix is doing the correct thing here. All they can know is that the emails are potentially different and so they should treat them as different emails.