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 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.
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 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.
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.
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.
Well that wont work. If you can't register with an email it's obviously because an account has already taken it.
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.
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 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.
Both the dot behavior and the even more common ‘+’ feature are perfectly spec compliant.
H: hi
Mom
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.
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.
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.
If you're going to try to "validate" an email address, read the goddamn RFCs.
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.
[0]: http://iamqasimk.com/2016/10/16/absolutely-zero-email-spam/
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.
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?
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[1] ...
[1] "Initially, before two-letter ccTLDs became standard, the Soviet Union was to receive a .ussr domain." (https://en.wikipedia.org/wiki/.su)
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 '.'
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.
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 jameshfisher@gmail.com account. And then you could still end up paying if you forget whether you ever signed up for Hulu or not (maybe you were about to sign up and didn't, maybe you planned to in the future).
Email validation seems like the most important defense against this kind of thing. Dots mattering seems secondary.
I think it was a valid design decision at the time, before accounts on websites were widespread and a family might only have a single email address from their ISP.
The rise of free webmail accounts from Hotmail etc changed that, of course. And now we have a shared understanding of how accounts on websites should work. Neither of those were true in 1994.
The justification I heard was that someone would have a personal and business (or library) account to the same email, but it definitely persisted longer than you think.
I had to jump through some hoops to get one of the accounts to test something I worked on with them.
As you point out, the only way around this email verification.
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.
In general we do it in two steps:
1. User detail and password
2. E-mail confirmation
Instead, if we did
1. User details but NOT password
2. E-mail confirmation and subsequently entering the password on the page that was sent via e-mail.
Actually, I think the most optimal would be
1. Enter e-mail address only
2. E-mail confirmation and entering all details
This would simultaneously protect the person that initated account creation and the owner of the e-mail address from one-another.
1. Enter email address and some out-of-band information that only an existing-account-holder should know. Eg: a web portal for a utility company could ask for the account number and amount due from a recent bill.
2. Send confirmation email with a code/link.
3. After user enters a valid code, continue registration by gathering additional user details, password, and (usually) recovery Q&A.
The user account is not created until step 3; if they provide a fake email, it's as if the registration attempt never occurred. Absolutely no access is granted until after the final step.
The extra details in step #1 only works for website registration of a user that has a pre-existing relationship with the company, of course. For a new account, email address is all you should request at that point.
Please though, anybody implementing signups - if you are going to let people sign up without validating email addresses, put a “I didn’t sign up for this account” link in every email you send.
As a user, I cannot trust that a website gets the recovery flow right. Some websites will allow you to bypass email and password if you know the answer to the question. Because of that, I cannot put in the real answer, as that would be a massive security risk.
So I usually put in some random garbage, which means it's essentially a second password. Well, if I lost my first password, chances are good that I lost the second password as well.
So please, don't do security questions. Just send a password reset link by email.
If you're worried about stuff like payment info stored in the account, just ask me to re-enter those details after I changed my password.
1. User must enter their email address, and I send them an email with a recovery code.
2. After they enter the code, validating control of the email address, I show them the Question they chose and let them enter the answer.
3. After they enter the correct answer, I force them to update their password, and I send a confirmation email about the password update.
The emails all provide contact information and ask the user to get in touch if they didn't initiate any of these actions.
You're right about the answer being essentially a second password, and I treat it as such: only an encrypted hash is stored, type=password fields are used to enter it.
One of my clients did request getting rid of the Q&A, which I was able to do pretty easily because email verification step and reset code were already implemented.
On a personal note, I never use real answers for security questions. I use randomly generated strings, just like my passwords. If I can choose my own question I use a random string for that too.
The possible disadvantage I see with the third option however is that if you are at a service desk, and they are trying to sign you up for a membership of some sort, they can't complete your registration on the spot. You would have to go home and use the computer to complete your registration (unless you can use email client on your smartphone). Which means they may lose a possible member if they don't ensure that you finish the registration right there and then.
For that reason it may be better to collect the email address, all customer details, and the desired password (typed twice). Then when the confirmation link is sent, the confirmation link should take you to a link that asks you for your password again (once) before your account is validated. This ensures that the person at the service desk is really the person using the email account to do the validation. Mere access to the email account should not be enough. The main advantage here is to make sure as little work as possible is left to the customer to do by himself when he gets home. I agree that this is a lot more messy than Doug Webb's approach, because the only accounts in that approach are validated accounts.
However to the extent that one does not want to lose a possible new membership because someone went home and decided not to continue the process because it is a lot of work, it may be worth it.
Google follows the standard, Netflix does not.
- alert@example.com
- A.Lert@example.com
- Al.Ert@example.com
etc. were different.
Requiring them to know or check what's the "local control" policy at each site may be a stretch.
Principle of least surprise, etc.
No, Netflix's errors lie in (a) sending e-mail for any purpose other than account validation to an unvalidated e-mail address, and (b) including a pre-authenticated link in the e-mail that bypasses the normal account access controls. Pre-authenticated links are poor security practice in general; e-mail is notoriously insecure, and simply being able to read an e-mail sent to the address on file does not imply that the reader should have access to the account.
As for "dots don't matter", it can be argued that Google made some scams a bit easier by routing e-mails to non-canonical e-mail addresses to users who don't realize they even have such addresses; my own recommendation would have been to block registration of e-mails differing only in the number or placement of dots, but bounce any incoming mail where the "To:" field doesn't match the canonical form chosen at account creation time. However, since doing away with the "dots don't matter" policy would not significantly impact the more general issue of e-mail address aliasing, I do not believe that Google's policies are to blame for this particular security gap.
On some systems, anything ending in '@example.com' may be a single account.
It may be that defined address to account mappings exist on a domain and all other addresses map to a default account. It's common enough the hosting industry supports it and it has a name - a catchall email account.
Nobody sending mail to any of those addresses needs to know how many addresses map to the account associated with the address to which they are sending. It's an address, not an identifier. I would argue you don't have a reason nor a right to know the address to account mappings in my systems.
What a sender should reasonably expect is that someone who can receive mail delivered to a particular address is in charge of the email account to which that address maps. Sending a verification email to someone expecting to receive it is the way to validate the recipient is the intended recipient. That's it.
If I give you my phone number, do you need to know what other phone numbers will ring that phone or how many phones I answer in order to call me? Do I need to disclose all the possible places I might receive a package if I want one delivered to a single place? No.
Email addresses are addresses. That's all they are. Stop pretending they are something else, and this will become much clearer for you.
The RFC also notes that the local-part MAY be case-sensitive (i.e. it's up to the host).
Edit: the host SHOULD ignore case: "a host that expects to receive mail SHOULD avoid defining mailboxes where [...] Local-part is case-sensitive".
(Similarly, although the RFC does say hosts shouldn't have case-sensitive local-parts, it doesn't say that senders can assume that local-parts are case-insensitive.)
But I also see his point about how this can confuse users who don't realize this or are not using this behavior intentionally.
They absolutely could. Netflix can't assume they are or they aren't. Which means Netflix is doing the correct thing here. All they can know is that the emails are potentially different and so they should treat them as different emails.
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).
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 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)
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 "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.
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.
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.
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.
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.
Sad, really...
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.
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.
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.
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.