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.
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.
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.
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?).
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.
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.
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.
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.
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.
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.
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.
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.
Fair points, and I'm not a fan of the recovery Q&A either. But here's the process that I use:
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.
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.
Maybe I don't understand the second option, but it seems to me that if you do the second option and a wrong email address is provided in step 1, then in step 2, the wrong person can take ownership of the account and provide his own password. So I agree with codetrotter that the third option is best of the three, to protect the two people from each other.
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.
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).
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.
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.
Nope. RFC 5321: "the local-part MUST be interpreted and assigned semantics only by the host specified in the domain of the address". That means it's actually technically against the RFC to do any normalization of the local-part (like ignoring dots or case).
My point is that the RFC doesn't say they "don't matter", it says they don't have to matter. For Netflix to assume they don't matter would be in violation of the RFC (it would be assigning semantics to the local-part).
Doesn't that support what Google is doing? Google is the host specified in the domain, and they are interpreting the local-part to refer to the same mailbox if they only differ by dots.
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".
It does. The relevant RFC says they don't have to matter and that senders shouldn't assume they do or don't. That means that both Google and Netflix are following the standard. The problem isn't with either company's compliance with the RFC, but that's not saying a lot. A mail provider could legally ignore all vowels in mailbox names.
(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.)
By that logic, jacksmith@example.com and johnjsmith@example.com could be delivered to the same mailbox. When I read TFA my first thought was "what does the standard say about it" and it does sound like Netflix is the one making the wrong assumption here.
But I also see his point about how this can confuse users who don't realize this or are not using this behavior intentionally.
> By that logic, jacksmith@example.com and johnjsmith@example.com could be delivered to the same mailbox.
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.
Yup. Since I run my own email server, I have 200 email addresses that are delivered to a single account. Some are service accounts (like postmaster@example.org) but a lot are single-use email accounts to track the selling of email addresses and spam.
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.
Those are three different addresses. On some systems they may be three different accounts. On others they may be one account.
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.
