If you are sending private transactional emails you need to verify accounts first.
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 firstname.lastname@example.org, 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.
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"
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.
* Gmail: Dots are cool.
* Hotmail: No capes! I mean dots. No dots!
* Multiplied by 8 hundred gazillion domains...
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.
How will the user know that the registration failed and what to do about it?
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.
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.
As soon as you find a valid login, you can test all known passwords (plus variations) associated with it.
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.
Well that wont work. If you can't register with an email it's obviously because an account has already taken it.
Have you ever tried it on Yahoo? They wouldn't let me set my email address to yahoo@mydomain a few years ago, claiming that the "email owner" had blocked this: https://www.dropbox.com/s/t213wkajdz5753k/yahoolies.png?dl=0
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?
In short, Netflix cannot assume things after the '+' are irrelevant and Netflix absolutely cannot canonicalize random emails like that.
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.
The acceptibility of the '+' character is specified in RFC 5322 .
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.
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.
Making users retype the email (instead of merely click on a link) might be better for exposing scams but requires more work on the user’s part.
+ 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 email@example.com has been confirmed, but firstname.lastname@example.org 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.
Both the dot behavior and the even more common ‘+’ feature are perfectly spec compliant.
If you're going to try to "validate" an email address, read the goddamn RFCs.
The other would be that spammers know that anything after a + is usually optional and strip it. Can't do that when the delimiter is a '.'
Which is odd, since there are some very, very old TLDs that are "long" ... I am thinking of .bitnet, .uucp and even the old .ussr ...
 "Initially, before two-letter ccTLDs became standard, the Soviet Union was to receive a .ussr domain." (https://en.wikipedia.org/wiki/.su)
I describe this technique in my blog post. I'll warn everyone now though, you'll probably want an email address for real people that you trust (like +email@example.com). 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 firstname.lastname@example.org. 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 email@example.com. 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 firstname.lastname@example.org. 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 email@example.com, 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.
Would not recommend to anyone.
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.
Are you DIY'ing everything?
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.
Server can decide for non-standard behavior, but that would be foolish.
Muhammad.(I am the greatest) Ali @(the)Vegas.WBA
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.
H: hi Mom
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.
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.
firstname.lastname@example.org resolves to email@example.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 firstname.lastname@example.org resolves to email@example.com -- a completely different address than firstname.lastname@example.org.
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.
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.
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.
But I don't think a scam that relies on you resetting the password and not becoming suspicious is a bit of a stretch.
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 email@example.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.
As you point out, the only way around this email verification.
I think it was a valid design decision at the time, before accounts on websites were widespread and a family might only have a single email address from their ISP.
The rise of free webmail accounts from Hotmail etc changed that, of course. And now we have a shared understanding of how accounts on websites should work. Neither of those were true in 1994.
The justification I heard was that someone would have a personal and business (or library) account to the same email, but it definitely persisted longer than you think.
I had to jump through some hoops to get one of the accounts to test something I worked on with them.
In general we do it in two steps:
1. User detail and password
2. E-mail confirmation
Instead, if we did
1. User details but NOT password
2. E-mail confirmation and subsequently entering the password on the page that was sent via e-mail.
Actually, I think the most optimal would be
1. Enter e-mail address only
2. E-mail confirmation and entering all details
This would simultaneously protect the person that initated account creation and the owner of the e-mail address from one-another.
1. Enter email address and some out-of-band information that only an existing-account-holder should know. Eg: a web portal for a utility company could ask for the account number and amount due from a recent bill.
2. Send confirmation email with a code/link.
3. After user enters a valid code, continue registration by gathering additional user details, password, and (usually) recovery Q&A.
The user account is not created until step 3; if they provide a fake email, it's as if the registration attempt never occurred. Absolutely no access is granted until after the final step.
The extra details in step #1 only works for website registration of a user that has a pre-existing relationship with the company, of course. For a new account, email address is all you should request at that point.
As a user, I cannot trust that a website gets the recovery flow right. Some websites will allow you to bypass email and password if you know the answer to the question. Because of that, I cannot put in the real answer, as that would be a massive security risk.
So I usually put in some random garbage, which means it's essentially a second password. Well, if I lost my first password, chances are good that I lost the second password as well.
So please, don't do security questions. Just send a password reset link by email.
If you're worried about stuff like payment info stored in the account, just ask me to re-enter those details after I changed my password.
1. User must enter their email address, and I send them an email with a recovery code.
2. After they enter the code, validating control of the email address, I show them the Question they chose and let them enter the answer.
3. After they enter the correct answer, I force them to update their password, and I send a confirmation email about the password update.
The emails all provide contact information and ask the user to get in touch if they didn't initiate any of these actions.
You're right about the answer being essentially a second password, and I treat it as such: only an encrypted hash is stored, type=password fields are used to enter it.
One of my clients did request getting rid of the Q&A, which I was able to do pretty easily because email verification step and reset code were already implemented.
On a personal note, I never use real answers for security questions. I use randomly generated strings, just like my passwords. If I can choose my own question I use a random string for that too.
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.
The possible disadvantage I see with the third option however is that if you are at a service desk, and they are trying to sign you up for a membership of some sort, they can't complete your registration on the spot. You would have to go home and use the computer to complete your registration (unless you can use email client on your smartphone). Which means they may lose a possible member if they don't ensure that you finish the registration right there and then.
For that reason it may be better to collect the email address, all customer details, and the desired password (typed twice). Then when the confirmation link is sent, the confirmation link should take you to a link that asks you for your password again (once) before your account is validated. This ensures that the person at the service desk is really the person using the email account to do the validation. Mere access to the email account should not be enough. The main advantage here is to make sure as little
work as possible is left to the customer to do by himself when he gets home. I agree that this is a lot more messy than Doug Webb's approach, because the only accounts in that approach are validated accounts.
However to the extent that one does not want to lose a possible new membership because someone went home and decided not to continue the process because it is a lot of work, it may be worth it.
The idea that you can tell whether two accounts are the same is questionable; netflix should not be relying on it.
Furthermore, the hack is possibly much less serious (but nonetheless conceivable) even without any canonicalization issues whatsoever. Apparently, a user can trick netflix into sending email to arbitrary email addresses. Sure, this is likely not to be an issue if the recipient doesn't have netflix in the first place - but if you try 1000 times (which spammers and phishers are wont to do) - you may well happen to hit a person that'll pay nonetheless - perhaps they forgot which email they used for netflix in the first place, or perhaps they share an email account, or perhaps the real owner is dead/on vacation/otherwise unavailable and somebody else is tending the account and thus more gullible than usual.
Netflix should never ask for money from random strangers without making 100% clear what the context of that request is.
(If indeed this article is accurate, because I wouldn't rule out the chance that the author made some oversight earlier).
Lack of validation means that Netflix is emailing someone asking them to pay for something, who may be totally different than the person getting that thing.
Google follows the standard, Netflix does not.
The RFC also notes that the local-part MAY be case-sensitive (i.e. it's up to the host).
Edit: the host SHOULD ignore case: "a host that expects to receive mail SHOULD avoid defining mailboxes where [...] Local-part is case-sensitive".
(Similarly, although the RFC does say hosts shouldn't have case-sensitive local-parts, it doesn't say that senders can assume that local-parts are case-insensitive.)
But I also see his point about how this can confuse users who don't realize this or are not using this behavior intentionally.
They absolutely could. Netflix can't assume they are or they aren't. Which means Netflix is doing the correct thing here. All they can know is that the emails are potentially different and so they should treat them as different emails.
etc. were different.
Requiring them to know or check what's the "local control" policy at each site may be a stretch.
Principle of least surprise, etc.
No, Netflix's errors lie in (a) sending e-mail for any purpose other than account validation to an unvalidated e-mail address, and (b) including a pre-authenticated link in the e-mail that bypasses the normal account access controls. Pre-authenticated links are poor security practice in general; e-mail is notoriously insecure, and simply being able to read an e-mail sent to the address on file does not imply that the reader should have access to the account.
As for "dots don't matter", it can be argued that Google made some scams a bit easier by routing e-mails to non-canonical e-mail addresses to users who don't realize they even have such addresses; my own recommendation would have been to block registration of e-mails differing only in the number or placement of dots, but bounce any incoming mail where the "To:" field doesn't match the canonical form chosen at account creation time. However, since doing away with the "dots don't matter" policy would not significantly impact the more general issue of e-mail address aliasing, I do not believe that Google's policies are to blame for this particular security gap.
On some systems, anything ending in '@example.com' may be a single account.
It may be that defined address to account mappings exist on a domain and all other addresses map to a default account. It's common enough the hosting industry supports it and it has a name - a catchall email account.
Nobody sending mail to any of those addresses needs to know how many addresses map to the account associated with the address to which they are sending. It's an address, not an identifier. I would argue you don't have a reason nor a right to know the address to account mappings in my systems.
What a sender should reasonably expect is that someone who can receive mail delivered to a particular address is in charge of the email account to which that address maps. Sending a verification email to someone expecting to receive it is the way to validate the recipient is the intended recipient. That's it.
If I give you my phone number, do you need to know what other phone numbers will ring that phone or how many phones I answer in order to call me? Do I need to disclose all the possible places I might receive a package if I want one delivered to a single place? No.
Email addresses are addresses. That's all they are. Stop pretending they are something else, and this will become much clearer for you.
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.
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.
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.
For example I'm regularly cc'd on a list of a South African film production company.
I often get invites to parties from a group of students in Georgia.
And, someone seems to use a dot alternative of my name to buy sex toys! And that is just a few!
I used to send back the emails saying "Hey you go the wrong person" until I realized it has no effect on these types of group emails.
I cannot imagine the strangeness that must occur for folks with more common name combinations, and the idea that firstname.lastname@example.org is the same as email@example.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)
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.
This on service providers to implement secure access properly.
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.
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.
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 "firstname.lastname@example.org" is the same as "email@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.
Netflix second guessing the aliasing pattern is the bug
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.
If the email address matters then validate it, if it doesn't need to be validated then don't ask for it.
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.
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.
I set up a firstname.lastname account for someone. On other services (e.g. iTunes) they've used that combo with and without dots.
It's a nightmare trying to help them with password resets.
They're not an internet-savvy individual.
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.
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.
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.
Netflix should totally fix this, even my local public library asks for email verification after signing up.
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.
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.
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.
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 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.
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.
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.
Mind you, I’m saying you should have to give up your email because other people have trouble spelling, just stating how I’d handle it.
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.
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.
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.
These days I'll flag any email from a service as spam, no matter how well known, if there was no email verification step.
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.
Funny old world.
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.
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.
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 'firstname.lastname@example.org'
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.
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.
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.
Should we stop using a feature because some buggy apps don’t support it?
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.
edit: 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.
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 "email@example.com" but actually entered (or later changed it to) "firstname.lastname@example.org", 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.
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.
Right, but read the rest of the sentence:
> I also have access to the account because I own email@example.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.
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.
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.
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...)
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.
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.
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".
first.mid.last, firstmidlast, firstmid.last
Any others bounce or display the warning header suggested in the article.
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).
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.
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.
I've written about this before-
-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.
But the scam described by the author works because he victim already has an account registered with their Gmail address.
The warning could be a good idea
also I wish the email address of both the recipient and emitter were shown in a better in Gmail.
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: firstname.lastname@example.org
The other email addresses:
email@example.com, firstname.lastname@example.org, etc
...where the other addresses get misremembered as:
I get these peoples' emails, but that could be easily avoided if Gmail took note of the dots.
Something like this:
I dont know for sure if that's how the filter would behave, though.
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.
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.
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.
Sometimes I'll text the person and complement them on their choice of purchases- yesterday it was a stunningly large Domino's pizza order.
You can (should) also mark the messages as spam because whoever accepted that address without verifying it shouldn’t be sending emails to it.
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.
 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.
It would be nice if gmail's filters had "bounce" and/or "report as spam" as available actions.
They can work with customer service to get the email corrected.
People just mistype addresses and vendors don't verify
I also combat with the same problem from time to time.