Totally disagree with the conclusion. This is Netflix's issue for not validating the email account. Not sure if Uber has changed this since then, but back in the day I used to get the full ride details and receipts from someone else who mistyped their email.
If you are sending private transactional emails you need to verify accounts first.
Absolutely - his proposed solution - disabling the dots-dont-matter feature and retiring them does nothing to stop this exact same attack vector instead employing the '+' feature that he admires and wishes to retain.
The attack goes like this:
* Hammer the Netflix signup form until you find a gmail.com address which is “already registered”. Let’s say you find the victim jameshfisher.
* Eve creates a Netflix account with address jameshfisher+netflix
* Sign up for free trial with a throwaway card number.
* After Netflix applies the “active card check”, Eve cancels the card.
* Wait for Netflix to bill the cancelled card. Then Netflix emails jameshfisher+netflix, going to jameshfisher's inbox, asking for a valid card.
* Hope Jim reads the email to jameshfisher+netflix, assumes it’s for his Netflix account backed by jameshfisher, then (follows a link in the email and) enters his card 1234.
* Eve changes the email for the Netflix account to eve@gmail.com, kicking Jim’s access to this account.
* Use Netflix free forever with Jim’s card 1234!
Either they're both security liabilities, and they should both be removed, or the problem lies elsewhere.
> Hammer the Netflix signup form until you find a gmail.com address which is “already registered”. Let’s say you find the victim jameshfisher.
The bug is right here - you shouldn't be able to determine if a user account already exists.
If an account already exists:
- Logon shouldn't tell you that you have an account and the password was wrong
- Registration should send a "looks like you already have an account" email to the recipient with "maybe this wasn't you" warning, and the web form shouldn't indicate anything out of the ordinary.
- Password reset should say "if an account exists, we just sent it an email"
Agree that many steps can be improved. In real live, though, it's not so difficult to guess/find someone who has Netflix, and also find their email. That's a really weak security requirement, security shouldn't depend at all on that part (it seems more relevant for privacy to me)
Further, it is trivial to picture an attack where through some other channel, the attacker already knows the email address of their target, and has the knowledge that this victim has a netflix account.
If I only need these two pieces of information, neither of which is intended to be 'secret', then I might easily already have enough information to attempt this attack on (for example) my ex, or their new partner, or someone at either work or university that I dislike, even if I didn't have enough information to target a random person in another country.
It is good practice not to expose user's email addresses to attackers. It is breathtakingly bad practice to depend on those email addresses being secret.
You’re thinking too much like a programmer. It’s a single rule for a single domain that accounts for the majority of users.
The right thing to do is ask for a password, but absent that, accounting for gmail addresses seems worthwhile. It would save them getting a thread like this on hn.
Upon entering a valid email (whether it is already registered or not) the form will show the following notification "an email was sent to user@email.com with the sign up instructions, please follow the link in the email to continue the registration" (rewrite for more concise message)
If the user already exists the email will be a warning + a link to the password reset form
If the user does not exist, the email will be a link that confirms the ownership of the email address and the rest of the registration process.
An attacker trying to guess if an email is registered would not know, because the form does not give away that info.
And conversion drops right away.
On every of my projects as soon as "auto sign in" was dropped -- conversion dropped as well.
(assuming that the "conversion" is to make a user to register and do something afterwards)
I know that there should be some kind of compromise since any security measure added to secure accounts will lead to some inconvenience for users.
If your goal to make sign in process as smooth for users as possible you may want introduce as little steps as possible between their landing on a page and "purchase".
But verification of email address should be kind of mandatory and happen before something important will be sent to this email.
Many sites allow you to continue, but limit your account and nag you about verifying your email. This seems like more of a happy medium, if you're concerned about conversion.
because if you know someone's email address you have now also discovered that they have an account with a particular service which you should not be able to do.
Can’t you do this anyway on the service? You are assuming there is no rate limiting and the passwords are used directly as bearer tokens to access the site.
But since you are giving advice to the DESIGNER of the site, why not simply tell them not to use passwords? https://qbix.com/blog for example
It's a tradeoff between usability and security, and each site should make their own decision about what is right for them.
It obviously makes attacks like the one in the article easier, but there are other ways to mitigate that.
An example often given for when revealing an email is registered would definitely be bad is dating website and pornography websites - where identifying someone is a member alone could be embarrassing or compromising.
Outside of such scenarios, websites may decide the increased conversion from a more streamlined registration process and lower numbers of support requests for login issues outweigh the marginal security gains from hiding that information.
Fair warning. That does add a certain level (quite significant) of inconvenience to existing users though. But probably a happy trade-off for most people entrusted with protecting accounts.
> Registration should send a "looks like you already have an account" email to the recipient with "maybe this wasn't you" warning, and the web form shouldn't indicate anything out of the ordinary.
Well that wont work. If you can't register with an email it's obviously because an account has already taken it.
Moreover some broken email validators reject plus addresses. It's nice to be able to fall back on special dot combos when you want to keep track of sites selling your email to spammers.
I used to use + for that purpose and was always pretty annoyed when a website wouldn’t accept it. I’ve since dropped gmail for fastmail though so now I use sitename@sites.mydomain for all website registrations. No site ever rejects it and it works great for knowing where spam comes from, although I’ve had some funny phone calls where people were baffled that my email address starts with their website name.
Spammers already know the dot rules. Its fairly easy to identify a Domain Group (ymail/yahoo) or (google/gmail/somewhere.edu) and then strip and reapply certain rules based on what that Mail Provider allows.
That's true in theory. In practice however, I've had success with figuring out a service that leaked my dotted address (I used a dot because the service didn't validate email with plus). I think this is often the case too because, spammers don't really bother validating emails by postprocessing etc. and just sell the emails in bulk in shady markets
Thank you.. I use this feature in exactly the same way. As I read,I was sitting there thinking "I can't possibly be the only one who knows about,uses,and likes this feature". Disabling it at this point would seriously screw up my life. It also prevents people from registering all of those close variations of my gmail address, which I also like.
Perhaps Netflix people are to blame for taking +tagged mail addresses as different than the ones that are not tagged. It is a well-acknowledged [1] and commonly offered feature by the email providers that should have been accounted for.
Dots-don't-matter, on the other hand, is very specific to Google, and they simply do matter in many other (if not all other) email providers. I think Netflix shouldn't be blamed for not accounting for provider-specific, non-standard equivalences.
Email address verification alone doesn't seem to fix all the erroneous aspects of this issue: Let's say Netflix was requesting verification, and then you receive the email for the +tagged mail address. Shouldn't it say that you already own a Netflix account, instead of asking for a verification at that point?
The + thing is common but is absolutely not universal. I can alias individual + emails on my system just fine (which means that x+a@example.com and x+b@example.com are not equivalent) and most smtp servers allow you to set an alternate character (I set it to '.' and '_' so x.a@example.com and x_b@example.com are aliased together).
In short, Netflix cannot assume things after the '+' are irrelevant and Netflix absolutely cannot canonicalize random emails like that.
All of this would be still useless regarding the proposed attack concept, because eve@gmail.com is also eve@googlemail.com.
And domain aliasing is certainly out of scope of any email RFCs I saw. Netflix (and everyone else) may know about googlemail.com, but it's virtually impossible to know about all other cases.
I don't understand - won't this process fail when the person signs up for "jameshfisher+netflix@gmail.com"? Netflix will send a confirmation email to the real jameshfisher@gmail.com, and not confirm it, and so Netflix won't create the account. Things stop at this point.
That's incorrect. The validity of accepting the '+' character as part of an email address is part of the standard (-though it is a standard ignored by many prominent websites, aliexpress is just one example I believe)
The acceptibility of the '+' character is specified in RFC 5322 [1].
However, the behaviour where an address comprised of:
local-part "+" some-suffix "@" domain
is automatically routed to the address:
local-part "@" domain
it certainly not part of the standard. I find it very useful myself and would be displeased to see that functionality removed, yet this is certainly not part of the standard.
Yep. Bug is the ability for users to charge a credit card before verifying email.
Or did the victim in this blogpost also verify their email at some point?
Netflix could be forgiven for thinking that updating payment details via email = verifying email. But if the victim had to respond to two emails, the first of which is a “verify email for your new account,” the phishing would be less believable.
Ultimately, the viability of a phishing scheme depends on the plausibility of receiving an email from a source. In this case, Netflix does send emails about updating your card details when a subscription charge fails, so plausibility of receiving the email from Netflix is high.
Another symptom that this is a bug with Netflix is that they granted the ability for one user to trigger a crafted email to another user.
Ultimately the bug relies on how believable the emails from Netflix are. If I got an email from Netflix asking me to update card details, I wouldn’t be surprised because maybe my card expired. But if I got an email asking to verify my new account, I would be very surprised. I didn’t sign up for a new Netflix account. If after that, I got an email to update my card details, I would be alarmed because of the recent unexpected signup email.
+ Netflix can send an email about optionally(!) confirming a user's address.
+ Now, rather than disabling all features and slowing down on-boarding it is possible to update the communication towards unregistered users.
+ If an email has to be sent to an unconfirmed address, preceed it with a warning. If pietjepuk@gmail.com has been confirmed, but pietje.puk@gmail.com not, emails for the latter will have this warning automatically.
+ Remaining option: do you want to send regular safety requests to unconfirmed addresses as provider? Policy might differ. However, it is possible to use this email to tell the user about safety/security w.r.t. your system. I'd say yes.
Yes, I've received emails of the form, "You recently signed up on our website for Fooflix, please confirm by clicking here. If you did not recently sign up, please disregard this email. Anyway, now that this is a known problem, both Netflix and Gmail should take reasonable steps to mitigate.
Absolutely. I don’t blame people who don’t interact with email for not reading the relevant RFCs, but not verifying control and expecting local part uniqueness to mean uniqueness of users is obviously busted to anyone who has worked with email. This is Netflix failing to understand part of their product surface.
Both the dot behavior and the even more common ‘+’ feature are perfectly spec compliant.
I do the same thing, for the same reason. I haven't A/B tested both options or anything, but I know I've gotten spam where they stripped the "+" parameter.
Try using an email address with .wedding or .solutions TLD. Loads of absolutely brain-dead sites refuse to allow them, sometimes they validate by TLD length (all TLDs are 2 or 3 characters, apparently) or other times rejection TLDs they haven't whitelisted.
I like the idea of adding +spam@gmail.com, but it would be really easy for this to be invalidated by just stripping this from your email before selling it in a mailing list.
Instead of blacklisting the +spam@gmail.com email, you could whitelist emails like +netflix@gmail.com. You can create a filter so that if it doesn't match the whitelist - including stripping the plus - then it will be automatically binned.
I describe this technique in my blog post[0]. I'll warn everyone now though, you'll probably want an email address for real people that you trust (like +friends@gmail.com). Also, you'll rarely have to email companies, but it is a pain if you need to do it from the +plus email.
>Also, you'll rarely have to email companies, but it is a pain if you need to do it from the +plus email.
This is absolutely true, and it's very painful. I sadly now
recommend against using +plus addressing if there is a possibility you'll need to get in touch with support for a website for any reason, and I have a cautionary tale. So many websites have incredibly shitty "security features" and incredibly shitty code.
I had an account with a payment processing website with myname+website@mydomain.tld. They sent me an email requesting some additional info about a payment I was to receive in order for it to clear. I responded from myname@mydomain.tld. The automated system helpfully informed me that they can only accept email from the email in the account (argh). So I sigh, go over to the website, and change my email to myname@mydomain.tld. No luck---there's already an account with that email. OK, I might have created one before and don't remember. I try to login with this info, hoping I can delete that account, but can't seem to get the password right, and it's not saved anywhere. So I use the "Forgot Password" feature. Oops, it looks like I haven't finished the onboarding process with that account, and so I can't reset the password on it (who even thought of this?!). So I make an alias of website@mydomain.tld, change my email to that, and try responding from that alias. No luck. Turns out that you have to actually use the address they originally sent the email to. If you've changed it, oh, that's too bad---please open a support ticket with us.
It took around 7 days of back-and-forth and waiting for responses from support (lots of waiting!) to explain that I'm just trying to respond to an email they sent me, and a lot of canned responses from people completely misunderstanding what my problem is.
Thanks for sharing! You thought this one through more thoroughly than I have. And your closing line about it being impractical is unfortunately all too true.
I recently decided to ditch Gmail because I don't trust Google any more than Facebook. One nice side effect of this is that now that I'm using my own domain, all company signups can be to me@spam.domain.com, which is much harder to filter well.
I use my own domain, but still use Google for my email service.
I've had fleeting thoughts of moving away, but am pretty used to the Google's spam filtering, labelling, search, and not having to care about space or managing my own kit.
I delayed moving away for literally years for this reason, but in 2016 I finally made the jump to fastmail and it was much smoother than I thought it would be. I don’t get any more spam than I did with gmail. I still forward my gmail to my fastmail but typically when I get a forwarded mail I either cancel whatever subscription it is or update it’s email settings, so I get rather little forwarded now.
No one's saying that they aren't spec compliant, the writer is complaining that google doesn't tell its users that their inbox will include emails for more than 1 address.
When I get an email to an address that isn't exactly the same as mine (e.g. due to extra dots in it), desktop gmail does actually show a small informational link next to the receiving address saying something along the lines of "yes, this really is you; click here to learn more". I haven't seen this on mobile, although I use the Inbox app, so it's possible that this it's there on the vanilla gmail app
Even things at the right side of the @ are up to the E-Mail server. You can send an E-mail to @gmail.com or @GMAIL.COM and Google could be routing it differently.
It'll resolve the same in DNS, but what the user typed will be encoded in E-Mail headers, and you could route differently depending on whether it's upper-case, mixed-case or whatever.
The name part, per the standard, is case sensitive. However, some organizations I get email from canonicalize it to all caps - and one even removes the dots(!) and all-cap it, which for my gmail I have a filter that sends all non-dotted email to spam, since 90% of my spam is non-dotted. Since that particular email was important and I'd just happened to notice it in spam, I checked the capitalization change and called them and even managed to get through to speak with their email manager. He absolutely insisted I was wrong about it mattering and said they wouldn't change it.
Changing case could be a co's lazy way of checking for existing accounts. In a perfect world they would store the input as-is and also use a lower or upper func on the indexed col. I suppose if they are verifying emails with their users and not seeing a big drop-off in verified accounts, they probably don't care to be too exact. Removing dots from the user portion is pretty shitty though.
The domain being in any case for the purpose of delivery is part of the standard, but there's nothing I know if which would prohibit you from implementing local delivery and routing in any way you want once the mail is accepted.
You have no guarantee that the domain part case is preserved from what the user wrote, if it's not defined to be case-sensitive. So you can do what you want, but the input data are not reliable.
Yup. Even spaces are allowed if you put double quotes around the local part: “Kevin Spacey”@example.com. It’s really surprising, there’s very little that can be verified if you strictly follow the RFC.
> there’s very little that can be verified if you strictly follow the RFC.
That's not correct. You can reliably, completely validate all email addresses . . . by sending an email to them containing information that can be used to confirm the owner's identity. All together now: the MTA is the only source of "is it valid or not" for email addresses.
This is a common issue with text based formats and ietf/RFCs. HTTP allows comments in some headers. And allows line breaks:
H: hi
Mom
Is the same as
H: hi Mom
Bets on how many http clients and servers get this right? Without losing speed?
My guess is when you're not responsible for ensuring compatibility or having to deal with writing robust, fast, code, the temptation to be cute with your format overtakes things.
I, too, would expect that the most common pieces of software with massive amounts of engineering time invested get it right (but almost certainly with a performance hit). But I'd be unsurprised to find that one doesn't handle the http parsing spec correctly somewhere.
The issue is that such a spec is entirely unneeded and overly complicated. No benefit, only downsides. And for something as simple as basic parsing rules! Not even getting into anything that should be difficult.
Yeah they're both spec-compliant, but (IIRC, as of a few months ago), in gmail at least, there's a huge difference:
janedoe+acme@gmail.com resolves to janedoe@gmail.com, and the "+acme" is simply a useful bit of metadata for Jane to track the provenance of the sender's mailing list.
the "+" and anything following it are ignored. It signifies an optional suffix.
Whereas janedoe.acme@gmail.com resolves to janedoeacme@gmail.com -- a completely different address than janedoe@gmail.com.
The "." is simply ignored as
if it weren't there, making j.anedoeacme and jane.doeacme and janedoe.acme equivalent.
Yeah this is specific to how gmail chooses to handle these spec-compliant-though-often-mishandled characters, but anyone who works with email professionally absolutely has to come to terms with how gmail works.
Not only that, but apparently he was able to change Eve's account details without having to enter a password.
If instead Netflix had prompted him before allowing him to change the credit card, it would not have worked, because he wouldn't have known Eve's password and Eve wouldn't have known his.
All around very bad security design on Netflix's part.
But if you have to reset the password to update the credit card details, then surely the scam won't work because the scammer would no longer be able to use the account.
For this scam to work the "Update your credit card" mail must contain a credential that allows you to update the scammer's card without changing or being challenged for their password. That doesn't seem great.
Fully agree. All authentication operations should always be completely explicit and clearly display the identity you are authenticating to. An email link implicitly logging you in looks like completely unacceptable. The email to recover your password can be excepted, because it is clearly an authentication-related thing and maintain the invariant that at most one person is actually able to log in.
you still have session cookies, because AFAIK netflix doesn’t log out all your devices when you reset your password (though i think there’s an option for that?) so you can still set the password and email back if you have the session cookie maybe?
This gives the excuse for companies to request phone numbers. What if I don't have a phone (I am frequently without mobile phone access due to some personal circumstances recently, and it's a massive butt pain).
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.
I had a similar issue with Sony/PSN recently. Someone had registered their account and even though I received a validation email I didn't click the link. I then got a welcome-to email a few days later.
PSN's emails don't have a "This is the wrong email" link like some services do, and the US support page link geo redirects to a UK 404 page. I had to go googling for an email address to complain to in order to remedy this.
I agree, the responsiblity for this flaw ultimately lies with netflix. And if laying blame is a helpful thing to do, the blame lies with netflix.
But at the same time, in a purely practical sense the mockup at the end of the article showing an explicit warning about email being sent to a non-canonical address is clearly excellent and should be implemented.
> the responsiblity for this flaw ultimately lies with netflix
Indeed. You should always validate emails for accounts.
The amount of accounts I “have” and can’t cancel because of sites not doing any email-ownership validation is quite annoying.
> in a purely practical sense the mockup at the end of the article showing an explicit warning about email being sent to a non-canonical address is clearly excellent and should be implemented.
Gmail is doing something very nonstandard here and it’s absolutely their responsibility to inform users why they are getting emails on addresses (most?) users would never know about nor use.
I’d even say that having this feature on with infinite whitelisting by default is a security issue which should be resolved.
Preferably by only allowing explicitly whitelisted entries created by (the few) power users using this feature.
Why can't it be both sides' issue? I have a fairly uncommon first and last name, but I still get emails from the few folk who share my name combination, and I too have gotten sensitive information that I shouldn't have.
I cannot imagine the strangeness that must occur for folks with more common name combinations, and the idea that e.mail@gmail.com is the same as email@gmail.com just seems wrong to me. As far as I know, all other email services and providers treat such accounts as unique, and it's a strange situation with very limited benefit to the end user. While I have made use of "the dots don't matter", it's always been as a way of circumventing account restrictions. The casual convenience of "dots not mattering" seems like it's overshadowed by the difficulty this can cause (as evidenced with the article and my own experience)
Permitting separate "sarah.jones" and "sarahjones" accounts would be pretty bad, too. Too easy to impersonate people. "Dots matter but are not included in uniqueness checks" is probably the safest approach.
While you CAN strip periods in the local part of the email and convert them to lower case before checking uniqueness, you do this as the risk of improperly disallowing valid and distinct addresses. A better solution is to check for similar address and provide a prompt "do you already have an account with this address:" rather than completely blocking registration with that address.
However, you should definitely not do these things to the address that you save for the purposes of sending email because then you risk improperly sending emails to the wrong person.
In general, validating the format of an email address is both extremely hard and pointless (since only a small portion of mis-entries will results in an invalid email address).
Pretty much the only way to validate an email address effectively is to verify it by sending an email to it and expecting the user to click an email.
To be clear, I'm talking about what email providers could do to reduce the risk of confusion, not what email senders should do to validate emails. I agree that the only way to validate an email address is to send a confirmation.
Except it does little to nothing to reduce confusion. It does nothing to fix the problem of people signing up using an email with a typo or with an email that doesn't actually belong to them.
This on service providers to implement secure access properly.
I'm not thinking primarily of transactional emails here. If Gmail allowed dots and allowed registering both "jane.smith" and "janesmith", Jane Smith would be well-advised to register both, because it's going to be the most common mistake people make. It's the same principle that suggests that if you own a .org address you should probably go ahead and buy the .com, too.
Gmail is a fairly common mail host. Doing what you suggest for ‘@gmail.com’ addresses would be an easy solution.
You could also make the case that Google should have a free library for most common languages that does this for you. It would improve the safety of their users immensely.
I may, however, be somewhat biased as I am the frequent recipient of email from weird services that some other chucklehead keeps signing up for even though he has yet to get past email verification as he doesn’t own the address.
> You could also make the case that Google should have a free library for most common languages that does this for you. It would improve the safety of their users immensely.
Please don't. I don't want an official library to exist to facilitate people harvesting and selling my email address without me knowing the source of the leak.
> I may, however, be somewhat biased as I am the frequent recipient of email from weird services that some other chucklehead keeps signing up for even though he has yet to get past email verification as he doesn’t own the address.
And you have existing accounts with all of these services? Or how does this relate to service providers striping dots when checking uniqueness?
You should report those emails as spam. If you never verified the email address they have no right to continue to send emails to you.
Even if Google didn't provide this feature to their users (and it is a feature that I regularly use to track who leaks my email address and then auto block emails to that address), Netflix's approach of sending sensitive emails without verifying the email address is still prone to security problems. Many people have multiple email accounts, or aren't really aware which email account they used to sign up. Sending a "please update your billing info" without verifying the email account first is purely on Netflix.
>This is Netflix's issue for not validating the email account.
Eeeh, I just re-read RFC 2822. It explicitly states that the local-part of an address may contain any number of dots as long as they are separated by (if I'm reading this correctly) at least one character, and do not start with a dot.
There's nothing in there that states you should treat dotted and undotted variants of an address as the same address.
So, google isn't violating the specification, but they are extending it in an unexpected way. Google could extend it further by implementing a "giraffes don't matter" policy where any instances of the word "giraffe" are recursively snipped out, so that "test@example.com" is the same as "tegirgiraffeaffest@example.com", but if they did it would be a bit rich for them to expect the rest of the world to adapt code to that decision.
It might be reasonable for google to expect others to handle this "dots dont matter" policy if it was some kind of defacto standard, but AFAIK it's not. I would argue that this form of attack is uniquely enabled by the gmail devs making a decision to add additional behavior to an otherwise well-understood spec, and that it's not netflixes problem to solve that.
To be frank, netflix can't solve it. Asking netflix to change their code will only solve it for netflix, gmail users will still be "at risk" from, you know, potentially literally every other domain on the internet.
So I would say that this is a risk that gmail users need to be aware of and mitigate themselves, perhaps by taking such drastic steps as reading their bills before paying them.
I see a lot of claims that email addresses should be verified prior to a transactional email being delivered - that that’s the “norm” or stupidly obvious way.
But when there is a real consequence on a conversion funnel for requiring email address verification (say ecommerce), I imagine the obvious business decision is to do the exact opposite.
It's about risk management. In this case they decided to take on the risk of account information leaking by not verifying the address instead of the risk to account conversions. The former shows more care toward their users and the latter shows more care to their bottom line. You can argue which is the right decision all day long but ultimately is a question of risk tolerance.
What's the point of a conversion funnel that creates exactly one conversion and then a huge amount of customer grief when they can never use the account again?
If the email address matters then validate it, if it doesn't need to be validated then don't ask for it.
I don’t understand what you mean by a “CF that creates exactly one conversion”.
Anyways, your response isn’t relevant in that I’m not suggesting an email address should (not) be verified. Rather, we’re discussing whether verifying identity needs to come before or after (or alongside) the transactional email - e.g. a receipt of purchase.
At the same time, validation and verification are not the same thing - and sometimes it’s not necessary to perform address/identity verification.
I have the same problem with Netflix, Uber and other sites. They simply do not check the email. It's an absurd. And the biggest problem is that the person who mistakenly uses my email asks a hundred times to reset MY password. Gmail and these sites need to take this issue more seriously.
This has happened to me with quite a few websites (netflix, nytimes, dropbox, and many smaller more localised websites for small businesses / services): people somehow seem to have registered and/or added payment details with an email address they don't own.
I get these types of things nearly daily since everyone mistakenly assumes they have my gmail account, single first initial and common last name. Many services don't require you to confirm e-mails, this is the problem. My apple ID account was created by someone else and they set the security questions and if you "forget" all the answers you cannot reset them online!
Only services I've seen that handled this properly are gmail and snapchat which send a verification e-mail to the entered address (for gmail its the secondary) and there is a link that you can click indicating your e-mail should not be associated with this account.
Totally... different services provide different ways to have multiple addresseses. The article already mentions one (plus addressing), but there are also others (like FastMail's subdomain addressing)[1]. And many people have catchall or misspelling addresses on their own domain.
That said, I dislike Gmail's "the dots don't matter" since it really screws up calendar invitation handling, because calendars don't handle aliases well.
What you say can be applicable for subscription billing. But there are hundreds of other sites and apps where you can "checkout" stuff without needing to register, which is also a welcome/better feature. And yes, they do notify when a transaction failed.
You cannot ask a whole ecosystem to change because of a feature/flaw on a central vendor. Where will you start? Force people to create accounts and verify emails when buying a one-off train ticket or ordering a pizza? What if people/market don't want this registration/activation crap for doing small utility stuff? For a payment, I have to authenticate with my payment provider, not to my email vendor. And payment providers do have delayed reconciliation issues that are sometimes notified back. And where would you stop? Validate each and every piece of info the user provides? Send a SMS verification code to the phone for same utility bill?
The conclusion is correct: Fix the vendor. I asked for a specific email address when I signed up. Similarly I should get emails only for "dots" that I have specifically opted in to. Deny receiving the email, show me a warning, don't allow it until I opt in. Anything else is just asking for trouble.
Absolutely. Netflix is using ID created by some other service as their ID without verifying with the other service if the ID in question belongs to the user who is claiming it's theirs. There needs to be a 2nd factor to confirm whether an ID belongs to someone - password/confirmation/code/pin which Netflix doesn't use here at all.
EmIl address is an identity. The core philosophical issue here is that an identity provider assigns you bucket of identities without your knowledge. Now others who do have knowledge of your assigned identities can take advantage to impersonate you. The idea that it can be resolved by email verification does not hold well because in several circumstances it might not be possible (for example, you need to create your account at the PoS). It’s a bug indeed if you think of email address as identity. It’s unrealistic expectation that all non-technical users should be aware about this feature as well as that all login system must use email verification.
The solution is simple: email provider should let user create additional identities with their knowledge. That is by default dot feature is not enabled but user should be able to go in and create alternative identities that they want explicitly.
Agree, this said the "dot don't matter" is also an awful thing. I'd rather have gmail create a real alias system instead of this hack. That's the thing that is good with Yahoo.mail, it has real alias system.
Eh, but consider online shopping carts. I go to some ecommerce site, enter in my email to buy something. If I have to verify the email first, conversion rates will plummet. Instead, (and this is what we do at my company), we attempt to validate that the email is a real one with MX lookups and even SMTP checks. But otherwise, you just have to trust the shopper.
The verification e-mail is going to say something like "Please verify this e-mail address for your new Netflix account", which is going to look very suspicious to anyone who didn't just sign up for an account. As phishing attempts go, this is not likely to be very effective. It's not nearly as bad as skipping right to the part where they ask for updated payment information (with a pre-authenticated link!)—someone who has a Netflix account, and perhaps a credit card which recently expired, has no reason to suspect such a request, and most likely would not notice that the e-mail address the notice was sent to does not match the one they used when setting up their own account.
And if they do require a verify, they should make it obvious that it was user initiated just then. Otherwise it could be the same scam: Eve creates an account. James gets the email. "Hmm that's funny. Okay I'll verify again".
I have a very common name and signed up for gmail address right at the start. I now receive tons of spam because there are people who sign up to the weirdest things with my gmail handle.
These companies are stupid and not worthy of respect. Not only Netflix, but Apple and even some banks don't (or didn't) verify email before sending private information.
If you have a bug in a system, do you fix it at the source, or do you fix it at all the leaves? Netflix might be wrong here, but fixing it at Netflix doesn't make the problem go away. Fix the problem once (GMail) and never ever have to deal with it again.
There is no bug in Gmail. This bug has nothing to do with Gmail, it is with Netflix not clearly communicating when verifying the address a user claims to own.
While I agree with you from a technical perspective, Netflix isn't going to be the only one with this particular issue. If you addressed the issue at gmail, you can be sure you've fixed it for all the little leaves.
The problem with this reasoning is that doing away with the "dots don't matter" policy would not fix the more general issue of e-mail aliasing. Besides variations in dots, there are also "+labels" (which Netflix must also consider a valid and necessary part of the e-mail address, per the RFCs) and the fact that for every "xyz@gmail.com" address there is an equivalent "xyz@googlemail.com" address. Unlike "dots don't matter", labels are a useful and well-liked feature, supported by many mail servers (though not always using "+" as the delimiter). Removing them would be an extremely unpopular move on Google's part.
No account-related emails (other than e-mail validation) should be sent to the e-mail address on file until it has been validated. Period.
The bug is in humans. Heck, I regularly come across people who think the case in an email address matters! While there is no bug in Gmail, that is irrelevant because you have to deal with the reality of how people use your product. Its basic engineering. Standards are simply a means for interoperability. In this case, the dots don't matter much for that goal.
RFC-5322 (the current standard for Internet Message Formats) in section 3.4.1 states, "... how address is used and how messages are transported to a particular host is covered in separate documents, such as [RFC5321]."
RFC-5321 states in section 2.3.11: ''The standard mailbox naming convention is defined to be "local-part@domain"; contemporary usage permits a much broader set of applications than simple "user names". Consequently, and due to a long history of problems when intermediate hosts have attempted to optimize transport by modifying them, the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address.'
Furthermore, it states in section 2.4: 'The local-part of a mailbox MUST BE treated as case sensitive. Therefore, SMTP implementations MUST take care to preserve the case of mailbox local-parts. In particular, for some hosts, the user "smith" is different from the user "Smith". However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged. Mailbox domains follow normal DNS rules and are hence not case sensitive.'
While you are pedantically correct, to me that reads, "don't try to change the case of the local portion of email addresses and apply no meaning to it." In other words, treat it "as-is" and assume nothing about it.
If I send an email to John@company.com instead of john@company.com and the server of company.com is configured to be case sensitive, then john will never see my email.
And we don't know when it will matter and when it won't matter, therefore we have to assume that it does matter unless we are sure it doesn't for our specific case.
I wasn't trying to be. I was mildly annoyed that this person was being needlessly pendantic about an irrelevant point that doesn't matter in any way whatsoever in the real world. They failed to give an example that matters.
But you can’t put the cat back in the bag. People have used the system to sign up for multiple emails at multiple sites, expecting them to go to the same inbox.
I suppose you could solve the problem by grandfathering all existing aliases and whitelisting delivery of only those that received at least one email before the policy change. And also continuing to forbid registration of any aliases.
Of course they know. They delivered the emails to the aliases, which are permanently in the To: field of the metadata. As long as you can see the email “to” address in the gmail web interface, so can Google.
completely agree, I've a rather common name with a corresponding gmail, it's absolutely shocking how little validation major Airlines do around emails!
If you are sending private transactional emails you need to verify accounts first.