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!
I have multiple "e-mail doppelgangers" - confused people who don't know their own email address and so accidentally use my address when they register stuff.
One's in Chile. I have almost no knowledge of Spanish. The other is in California.
Having experienced this:
Services need to email new email accounts they become aware of ASAP. They have literally zero UI available to me to notify them that this is an invalid email address. The very first interaction when a user registers an account with their email on the service needs to be "Welcome username to MyCompany.com! If you didn't create an account with MyCompany, click here to let us know and we'll remove the email address from this user's account!"
If Netflix does not do this, Netflix is doing it wrong. It also would solve your security issue - by immediately notifying the address that a new account has been created on them, it notifies the user to expect additional emails and allows them to take action immediately.
This also prevents another problem: What happens if somebody has already accidentally claimed my email address on a service I want to join? If you don't provide a way in the emails to say "that's not me", then I have no way to ever register for your service with my address.
I have a very short email address and get lots of these. What I do is immediately log in to the service and change the password. Then, if possible, I log out any other devices that are logged in.
Then they can never access the account and continue to to use the service.
Where available, I will delete the account as well.
I found that if I don't do this, then I am just going to be receiving notification emails forever from that account.
I actually have dots in my Netflix account email address because somebody who wasn't me had previously started to register for Netflix using my email address.
I have had to do this with some other services as well. Some services won't allow the + in gmail addresses, which is pretty annoying.
If a service starts recognising the dots don't matter and denying the plus symbol, there's a good chance I won't be able to register without obtaining a new email address.
I wouldn't mind but my name is really not that common -- my surname is uncommon enough for me not to have met another with that surname outside my family.
The thought did cross my mind. But there's something that feels weird about claiming an account that I never set up, especially where it's not clear if the service allows payment or usage with an unverified email address.
I personally don't believe the penalty for putting my email address in instead of yours (which could be very close) should be complete account hijack. Instead, I usually just filter the messages to trash.
I would much prefer to be able to click a link saying "I didn't expect this email." Very few services actually do this.
There will be some people who read the OP and see treating dots in email addresses where dots don't matter as another thing on their todo list for a signup form.
A more considered approach would be to think about how you handle emails. A lot of the time the email is the most important thing -- access to the email address is often the only credential you need to get into the account, so you want it to be correct before anybody spends time entering details.
You can make sure there are no mistakes by giving users a link to click within a window of time (e.g. 7 days), before they can enter any data associated with that account. Provide a link that says "nothing to do with me." Do not count the account as real until the link has been visited.
In the case of the linked article, Netflix asking for billing information before confirmation of email address is a clear example of a threat vector that has far more to do with Netflix prematurely pestering for payment than it does with Gmail aliasing email addresses.
Yeah, that. While the dots may present a marginal security risk, they provide a useful workaround for sites that fail to allow the owner of an email address to remove their address from another user's account.
Same with me, I have someone who is in the US (I'm in the UK) who has registered for a university and attempted to buy a car using my email address.
They must be fairly disorganised as I keep getting emails about overdue library fees. No matter how many times I email these places, they never remove the email from their system. I'm hoping GDPR might give me a hand with that, though I'm doubtful if they're places like a US University.
Email validation is a must for all services, people make mistakes and clearly some people don't even know their own email address. This is a problem with both Google and Netflix. Netflix are being negligent and Google should retire this feature.
I have this problem a lot as well. There was someone with my name with a Bank of America account that regularly bounced checks, and BoA provided no way to disassociate my email address from the account.
These days I'll flag any email from a service as spam, no matter how well known, if there was no email verification step.
Yup. I had some guy's credit card bills appearing. It was actually super weird - somehow Google had metadata about the credit card bill that was not in the body of the email, so I'd get "reminders" on Google Now saying "pay $1200 to Notyourbank by the 1st of Octember", but I couldn't actually see that bill without logging in (which, obviously, I could not and did not try to).
Btw that meta data I believe it's in the body of the email. Hidden with some html tags that Google tells companies to use so they can do those things. Inspect the source of the html of the body and see if you can find it there.
I have the same issue, except I have a 6 character nickname using 3 unique characters at gmail and people use it for all sorts. Games, flights, utility bills, shopping sites, phone contracts, dating sites and much more. From all over the world. I had someone else's dropbox too, and even after the continued warnings they would cancel it and had cancelled it there were messages to access it still, that it was still there with the ability to view data.
The strangest by far though is the huge amount of gmail accounts created with my email as the backup. I have to assume that wording on some localisations indicate you need one so they mash the keys and pop in my gmail.
So I have hundreds of security alerts for recovery and notifications it has been set.
Same here. I have a six character gmail address which includes a common name, and I get an average of between one and two misdirected emails a day, sometimes more. Stuff from all over the world, signup emails, invoices, love letters, confidential documents, etc. Mostly the non-dot version, but sometimes a version with one dot. It's infuriating, but I couldn't possibly change my email address at this point; it's tied to hundreds of accounts :(
It's funny, saying "email doppelgangers" reminded me that I have the same issue with phones and physical addresses (but not email since I use a unique domain name).
I get multiple snail mail bills for DirecTv to people with different names but my address. One of them apparently didn't pay, so now I'm also getting collections letters addressed to them at my address.
I've also had someone in Oregon use my google voice number at some doctor's clinic, so I was getting voice mail transcriptions about appointments and certain tests that needed to be run.
Turns out lots of people just can't figure out their own unique ids, whether they're email, phone, or home address.
Yep, same here. I've got a "DJ" in the US, but also a guy in India. The Indian guy is always getting legal threats for not paying his phone bill.. I feel a bit bad that he's not even getting the emails, but I have no idea how to actually contact either of these people...
On in New York used by to confirm a doctors appointment (with some information on their condition). They also gave my address to their broker who sent an account summary. Bond portfolio in the millions.
Some lunch delivery server in Mumbai sends sends out emails to the address provided with no option for me to remove my address.
Another one or two in the UK who put me down for random stuff.
I just got one for a hotel booking. Google usefully added it to my calendar.
"My" X-Box live account seems to have gone.
I did enjoy repeatedly rejecting "parental" permission for some kid to join Club Penguin though.
One of my emails is a "one name" gmail address so I get a few of these fairly often. I've tried doing the good thing where possible and trying to get it changed by contacting the provider but I just gave up. If I get more than a couple of emails from any account, I just hijack it permanently; I've found that deleting the account will only lead to the offender recreating it.
I have the same issue, but Uber has 2FA on the account through SMS. This way I can't login to cancel the account, and there is no 'unsubscribe here' link in the emails.
Also had someone use my email to sign up to an airline. After messing with the seat assignment and meal selection a few times it became old and customer service didnt know what to do, so I changed the associated email to 'helpdesk@airline.com'
Even funnier was how a gameshop website that I did have an account with actually changed my password and account details to be assigned to someone in another country. No notifications etc... So now there are a bunch of trade-in credits on my account, after changing it back to my own details.
> If you don't provide a way in the emails to say "that's not me", then I have no way to ever register for your service with my address.
This happened to me - someone registered an Uber account with my email address. So I password reset it and now I have an Uber account for no good reason.
I don’t get the argument that the email dots stripping should be removed but the “+” tag feature should be kept.
Both of them allow infinite email addresses. The tag feature is not always available because app developers frequently don’t allow the plus character.
I would prefer that (1) a Netflix require email verification and (2) GMail describe in detail all of the email address features so app developers can explore the security issues around them.
I used to work for a company that dealt with these issues almost 10 years ago. It was also fun when Hotmail and Yahoo started recycling unused email addresses after ~6 months.
This is why, on my semi-personal (<10 users) email server I process several different characters as tagging characters: dot, dash, underscore, and plus IIRC.
I use a subdomain as catch-all; *@something.example.com all goes to one folder. That way it's impossible for the spammers to know that this is a "sorted" e-mail address since lots of people have e-mail addresses under a subdomain and it's not trivial to filter out like myrealidentity+youareaspammer@example.com turning into myrealidentity@example.com.
Other users on my setup can use it, they just have to pick a different "something" if they want to use the same example.com as me.
I'd say most "non-technical" users dont even look at the email address it was sent to. They just assume that since it landed in their inbox, the magic 'computer' knows what its doing and they just need to read their email and reply appropriately.
My understanding is + sign is in the RFC, so of course it should be supported. If you want to identify your users by email, you should probably strip the + and everything after before checking for uniqueness. On the other hand, dots matter in the RFC and Gmail is breaking it with their "feature".
edit: I was corrected in other comments that the + labeling is optional part of the standard.
> I was corrected in other comments that the + labeling is optional part of the standard.
Allowing + in emails is not an optional part of the standard.
> you should probably strip the + and everything after before checking for uniqueness.
No, you shouldn't. Different email providers use different characters to allow "subaddressing" or "tagging" and the presence of those characters doesn't mean that any subaddressing will be done.
Gmail isn't breaking anything. It's none of Netflix's business that Gmail gives its users aliases. This issue has nothing to do with dots, and everything to do with Netflix sending bills to unverified email addresses.
As far as I can tell it isn't in the standard at all, optional or otherwise (although the character '+' is allowable). Gmail are not the only ones to implement this feature though.
Also, you'll have to elaborate on how the dot usage actually breaks the RFC. I assume it states that dots are just like any other allowable character, but that's not the same as actually breaking the RFC.
The dots do not matter, this does not enable a scam, and 99% of people replying to this seem to have utterly missed the point.
First off, let's be clear: The story is about someone who entered the wrong email. They should have entered "eve@foo.com" but actually entered (or later changed it to) "james@foo.com", which means that James got some emails from Netflix about Eve's account, incorrectly assumed they were about his account, reset the password on Eve's account, and came close to entering payment information into it.
All of which is fine; this is how email works, and how modern services (correctly) use email: By identifying an account with an email address, and assuming that if you have control of the email address you should have control of the associated accounts.
The author is weirdly focused on the fact that gmail allows some flexibility in how the local part of the address is interpreted, but this is a feature of most email providers (yahoo, outlook.com, protonmail, and fastmail all do it), and is a feature offered by qmail, courier, and postix as well. It's also explicitly required by the relevant RFCs. And...
...it's utterly unrelated to the issue at hand. This isn't about how the local part is interpreted; it's about someone typing the wrong address that they don't control when they sign up for an account. Sub-addressing and the details of how some random mail server normalises the local part is not what this is about. If gmail bounces all emails with "incorrect" periods, it might have stopped this particular incident, but it doesn't solve the issue which is about people giving out your address instead of their own when creating an account, which is the actual issue here.
Further, the proposed scam, if it works, only works because (allegedly) Netflix lets you change an account email without verifying that you know the current password. This violates every tenant of account security; because email is used to prove you control an account (allowing, eg, password resets), changing the email obviously requires you to prove you control the account. You have to ask for the password! I rather suspect Netflix does, but if not, this is the core issue.
> the issue which is about people giving out your address instead of their own when creating an account, which is the actual issue here.
If the other person had tried to use the author's email address written exactly the same as his existing Netflix account, Netflix wouldn't have let the other person create a new account, but would instead have made them log into the existing account. The fact that Netflix and Gmail don't have the same notion of "existing account" IS the key issue here.
> the proposed scam, if it works, only works because (allegedly) Netflix lets you change an account email without verifying that you know the current password
Well, Eve knows the account's password at the time she changes the account email, the article explicitly mentions this: "Eve has access to account N2 because she set its password when signing up".
But this does touch on an interesting point. If Netflix required him to enter his password before he could update the credit card from Eve's to his own, then to go through with it he'd have to reset the password, so even if he went through with it and double-paid at least Eve wouldn't be able to reap the benefit of a free Netflix account, which is at least a less severe security issue than the current situation.
> Well, Eve knows the account's password at the time she changes the account email, the article explicitly mentions this
Right, but read the rest of the sentence:
> I also have access to the account because I own james.hfisher@gmail.com, and so I can follow the password reset process for this account. I did so.
So at a minimum, Eve did not know the password at the time they would have (hypothetically) tried to change the email, as James says he had reset the password. And at least based on my interpretation of the linked article, this is unavoidable; you can't manipulate payment details without being logged into an account, and the only way to log into his bogus second account would be via a password reset.
If that's true, your proposal is in fact the situation: You do have to reset the password, and there's no benefit to the "scammer"; at most you can trick someone into paying for two different Netflix accounts. And this does seem to be true; he provides the link as https://www.netflix.com/simplemember/editcredit?locale=en-GB which doesn't contain an account identifier and does (of course) require authentication.
> The fact that Netflix and Gmail don't have the same notion of "existing account" IS the key issue here.
Well, first it's worth noting that Gmail is following the relevant RFC here (as per RFC 5321 2.3.11 Mailbox and Address, "...the local-part MUST be interpreted and assigned semantics only by the host specified in the domain of the address."), so if Netflix is relying on the semantics of the local-part then they're simply in error. And second even without this there's a lot of ways of getting a plausible looking phishing email into someone's inbox. If Netflix security relies on targets not seeing a malicious email, then they've done something terrible.
The author is writing about getting a Netflix account funded by causing Netflix to send an email to a Gmail account holder. For all intents and purposes this is a legitimate email originating from Netflix. It is not about someone surreptitiously transferring control of another person's Netflix account to himself.
> It is not about someone surreptitiously transferring control of another person's Netflix account to himself.
That's exactly what we're talking about. Keep in mind that by the end of the proposed "scam", there are two accounts, both registered to James' email address, and with passwords that only James knows. He has control over both accounts.
Any attempt to profit from the scam would require surreptitiously transferring one of the two accounts James controls to someone else, which 1) may not even be possible 2) doesn't have anything to do with Gmail's normalisation of the local part of email addresses.
If there's an attack here, it's about Netflix not stopping an attempt at gaining control of an account when you do not control its email address and do not know the password.
Not really. There are two Netflix accounts, and both recovery emails are directed to James’s Gmail account.
The scam is operating on the chance that James does not realize that it is someone else's Netflix account and goes ahead to add funds to it. The other person then logs in before James realizes his mistake and changes the recovery email to something else.
> The scam is operating on the chance that James does not realize that it is someone else's Netflix account and goes ahead to add funds to it.
Right, but keep in mind that he's already changed the password.
> The other person then logs in
How? They don't know the new password.
The timing doesn't seem to work; James can't add funds without resetting the password, and Eve can't hijack it without knowing the new password. There's a potential loophole if Netflix 1) doesn't invalidate the old session when the password changes and 2) doesn't require a user to provide the current password for changing the email but as far as I'm aware, that isn't the case. (It certainly shouldn't be! And if it is, then that's the real issue here...)
The perp can regain access to the account by using alternative forms of account recovery in the account management settings, which the user would unlikely notice if he doesn't suspect anything amiss. e.g. an SMS password reset link sent to a phone number the perpetrator controls, or a secondary email address.
But he can't add funds to it without logging in to it, which requires him to reset the password. Once the password is reset, the scam can't benefit the scammer.
In order for the scam to work, either he has to be able to change the credit card details without knowing or changing the password, or the scammer has to be able to access the account without access to the password or e-mail address. Both of these are serious security issues, but not what the article was about.
> All of which is fine; this is how email works, and how modern services (correctly) use email: By identifying an account with an email address, and assuming that if you have control of the email address you should have control of the associated accounts.
That is not the correct way to use e-mail. Unless you're encrypting all your customer messages with S/MIME or PGP, a number of people have access to the content other than the account holder. This includes the e-mail provider, the operators of any servers the message happened to pass through, and of course anyone who happened to hack them, plus anyone who can listen in on the links between the mail servers in the event that those aren't encrypted. None of these people should have control over the associated accounts just because they have the technical ability to read e-mails send to the address on file.
> If gmail bounces all emails with "incorrect" periods, it might have stopped this particular incident, but it doesn't solve the issue which is about people giving out your address instead of their own when creating an account, which is the actual issue here.
The actual issue is more nuanced than that. This isn't just about signing up for a service with someone else's address, it's about signing up for a service the target already subscribes to using an alternate e-mail address routed to the same account. Now, it is absolutely true that getting rid of the "dots don't matter" policy would not prevent this from happening, since there are other ways of aliasing e-mail accounts such as "+labels". However, in the absence of aliasing this issue wouldn't exist, since someone who doesn't subscribe to Netflix would (probably) not fall for a request to update their payment information, and the scammer couldn't create a new account with exactly the same e-mail address as an existing subscriber.
> Further, the proposed scam, if it works, only works because (allegedly) Netflix lets you change an account email without verifying that you know the current password.
The scam does not require the ability to change the e-mail address. That just makes it harder for the target to regain control, but ultimately the scheme depends on the target remaining blissfully unaware that they're paying for someone else's account. If the target becomes aware of what is going on then they can just dispute the charges with their card issuer; they don't need access to the Netflix account for that.
No, this scam only works because Netflix does not require validation of the e-mail address on file before sending account-related e-mails to that address. This is the core issue. The first e-mail you get related to an account should always be the notice that a new account is being created, with active effort required on the recipient's part before the address is considered valid.
100% disagree. My standard gmail address is with dots but when I have to tell my (rather long because it is my full three part name) I either omit the dots or tell them they don't matter. Totally an important and useful feature. Netflix is at fault for letting someone else use your email without asking you for permission.
Although I agree Netflix is more at fault here, I think gmail could also make you aware if an email is sent to a non-canonical address. They do have the canonical version to compare to, whether that's with dots or without.
I also have to put forward that if you have trouble telling people your email address then you probably chose a bad address. You didn't have to put in the dots, and he isn't actually suggesting that they get rid of them now anyway. I point this out only because it means your use case doesn't mean it's an "important and useful feature".
DONT do this. I own the dotless version of an email address like this. I constantly get email intended for some realtor in California that does this. I see so much paper work that I should never see.
That's exactly how it works today with the added benefit that the user does not have to enumerate the list and it's hard for other people to squat on slight variations to your email.
Yes, in fact this is one of the more annoying parts of this feature. When you're doing a support thing you usually have to reply with the exact same email. In my Google Suite account I have many domains setup to a single account and often times a reply uses my main account instead of an alias+domain I've setup on the account which received the email.
Would be nice to be able to easily reply as any of those combinations and default to the one it was sent to (dots, +'s, and domain).
Because it's Netflix not adhering to the spec, which states that local addresses are to be interpreted by the host only. Netflix has no business caring about how Gmail interprets its local parts.
Well, if Netflix striped the periods, THAT would be not adhering to the spec. Netflix's issue is that they have a lax security practice, not that they don't adhere to the spec.
Gmail does adhere to the spec, which has nothing to do with this bug which is Netflix sending emails without verifying. Email isn't even relevant here. The exact same thing happens with postal mail addresses if something gives your address as theirs.
I really wish that I could tell google to bounce all the emails that don’t match my “dot pattern”
I’m now in complete control of someone else’s commercial business hvac account because of precisely this problem. And the worse part is that I don’t know the correct email to get ahold of this person. They’ve set up library appointments, I received a receipt for a down payment on a lake house, basically most of this persons recent attempt to start a commercial business has been emailed to me.
I don’t want this email google. Please give us the option to make it stop.
I'm now in complete control of someone else’s commercial business hvac account because of precisely this problem.
But that has absolutely nothing to do with the dots. Indeed, almost every comment about this has nothing to do with the dots, including the submission.
Someone entered the wrong email address, and in the process got yours. It isn't like the dotted or undotted one is legitimately theirs -- it can't possibly be -- but that they forgot a middle initial or something of the sort.
-but the issue is with email itself, and the notion that once someone enters an email address it is authoritative. Like you I get a tonne of email for other people. I get travel tickets. I get room reward points. I get calendar events for car service in England. The dots aren't the reason.
The scam works because of Netflix's lax security practices around verifying emails. Given how easy it is to make a mistake filling in your email address, and email address should never be trusted until it is verified AND you should make clear during your sign-up process that the user should expect a verification email so they know something is wrong when they don't receive one.
But the author reset the scammer's password, denying them access to their fake account. The scam doesn't seem to work unless Netflix allows you to enter a new credit card number /without/ resetting the password of the scammer's account.
I agree there's that fundamental problem with the way email gets handled.
But at the same time I still wish Gmail would stop you from receiving emails on addresses other than the one you created yourself (ie by treating dots like any other character). It'd save me from getting several misdirected emails per day.
It's true that all these misdirected emails come down to people misremembering their addresses, but I think you're overlooking an important class of such misremembering (which can be addressed on its own).
I have a dot in my actual email address. There are several people who have a similar address who must be forgetting that their email address actually contains an additional initial or number. However some of these people do not have the dot in their actual email address.
I.e my email address: this.that@gmail.com
The other email addresses:
thisnthat@gmail.com, thisthat7@gmail.com, etc
...where the other addresses get misremembered as:
thisthat@gmail.com
I get these peoples' emails, but that could be easily avoided if Gmail took note of the dots.
I have a concern with that. Say I train the filter to treat emails from company X as spam, and then in the future I sign up with company X and their emails to me get treated as spam.
I dont know for sure if that's how the filter would behave, though.
That's why you send an email to whatever the user typed in with a link they have to click before they can complete the signup process. This is really, really basic stuff.
That same problem can happen even without dots. People can simply mistype their email and have it be your email. That happens if even if neither of you have dots in your email.
You’re not missing anything, but if gmail delivers all the mail, and I just trash it, we’ve fixed the symptoms, but not the problem, and we’ve made the problem invisible.
I agree that sending verification emails should be the standard. But if I can’t bounce the emails then there isn’t even the slightest way to inform the sending service that there might be a problem.
Do you also, by chance, have a short Gmail address? I've also definitely gotten signups from other individuals mistyping their address on my six letter account.
My comedy ownership of someone else's identity is a Staples account. Presumably someone in New York with a similar name had a store person look up their Staples account, which was actually my Staples account, and associate their business name with it. Their business name now appears on mailings I get from Staples and sometimes I get sample pens and the like branded with their business name.
It’s not too short. 12 characters including the name separating dot.
This person that recently started using this email is using the same name but with no dot.
first.lastname@gmail is what I use, and now I’m getting a bunch for firstlastname@gmail.
Some of these emails look pretty important too, if I had malicious intent, I could probably ruin and or steal this persons identity and or business with the specific mail that I’ve received recently.
I’m really amazed at the lack of confirmation of emails before sending things like your HVAC business license, or city contracting permits, that have other people’s identifying information in them too.
Wouldn't the same thing be happening if they'd entered first.lastname@gmail, or if you used firstlastname@gmail? It seems like the problem is that they entered an email address that wasn't actually theirs. The dots don't seem to make a difference.
Just create a filter to send everything that doesn’t match your dot pattern to the trash. I have a relatively common first name / last name gmail account and it gets out of control sometimes.
My issue with doing that is that the other person will never get help. They’ll just say “oh my emails keep getting lost”, but if google would bounce them, then hopefully one of these services would notify the person that that isn’t their email. Instead of them happily continuing to send it all to me.
The amount of consideration I'm willing to extend to a person who either doesn't know their own email address or is trying to scam me isn't that great.
Sometimes I'll text the person and complement them on their choice of purchases- yesterday it was a stunningly large Domino's pizza order.
Don't see a way to do that in the web UI. There's a "To" box in the first page for filter setup, but no obvious way to negate so as to specify "NOT To".
You can create a filter on the “to” field of emails. Any email sent to the undesired dot pattern will have whatever action you choose taken on it. Put them in a folder and mark them as read or send them to trash.
You can (should) also mark the messages as spam because whoever accepted that address without verifying it shouldn’t be sending emails to it.
Something similar happened to me once [1] and I used the password reset process to "hijack" the account. I used that to contact them over facebook, and then assigned the account to their proper email address. They were quite grateful.
I'm not sure of the legality of that process, and you could argue the morality of it, but doing this once to one of their less important accounts (library?) might be a good way to get enough information to contact them properly.
[1] It wasn't technically the same, because the typo was done by a phone carrier agent, not the person whose account they were setting up. My email is firstname.unrelatedstring, theirs was firstname.theirmiddlename.lastname, but my unrelated string happens to be their middle name.
You may be able to set up filters to automatically trash everything sent to incorrect addresses. It might be fairly annoying, but it should certainly be possible. Just set a filter for firstlast@gmail.com to send them to spam. Also, software such as mailwatcher allows you to bounce emails after they've been received by the server if you think it necessary.
I just tried creating an account that differed from an existing account in the number of dots, and it was refused, explicitly on the grounds that periods and capitalization are ignored. Therefore, either at some point Google got this wrong and allowed the creation of such aliases to an existing account as if they were distinct, or this person is mistyping one of the non-dot characters of their address.
If you are sending private transactional emails you need to verify accounts first.