Say you have a website where it is possible to create accounts for all of the following email addresses:

'test@test.com '

Should this be considered a security issue? I've tested to see if you can access test@test.coms data while logged in as test@test.com; and you cannot.

In spite of the fact that you can't access the accounts created using very similar email addresses this still seems, at the very least weird and possibly like it could lead to a security problem, but I can't think any specific security issues that could occur as a result.

Can anyone suggest any specific security issues that this setup could lead to?

  • 1
    Hm... Well, I can think of plenty of systems where allowing "<email1>,<email2>" would allow someone who only has access to email1 to spam whoever has email2. And of course that has DoS potential; if you specify a list of addresses, of which yours is only one, they have to send a (roughly integer) multiple of the number of bytes you sent them, in direct relation to the number of e-mail addresses you specify. – Parthian Shot Jan 27 '16 at 21:05
  • 1
    @ParthianShot but that's not really a problem with nearly identical email addresses. Ideally, something like that should be caught when registering, but it's more of a vulnerability of the used mail function/library, which should make it explicit in its interface if there is one recipient, or if there are multiple recipients, and deny invalid input. – tim Jan 27 '16 at 21:18
  • 8
    I am really tired of people spamming my email test@test.com... would prefer if you used someone else's email as an example. – blankip Jan 27 '16 at 23:37
  • 5
    @blankip The domain reserved for use as an example would be a good bet. – Blorgbeard is out Jan 28 '16 at 1:33
  • 1
    Note: just please don't be too restrictive on your email addresses if you try to validate them. See I knew how to validate an email address until I read the RFC. Once you've determined that the basic pieces are there, you can ONLY send the email and see if the user gets it. You have no business preventing valid email addresses from use by being too restrictive! – ErikE Jan 28 '16 at 21:10

The one and foremost problem with this approach is that in your example, only the first one is actually a syntactically valid email address. The three others are not. This means that one of the two following options holds:

  1. The "email address" is merely a suggestion. The system wants a unique login identifier; email addresses are reasonably good identifier because users remember them, and the email system already ensures worldwide unicity.

  2. The email address is really supposed to be an email address (e.g. to send emails to that address), and the registry system totally fails at validating that whatever the user entered is an email address.

In the latter case, this means that emails fail to be conveyed, and also that the developer was very sloppy with regards to user input validation, which is not a good sign for security, generally speaking.

However, if the identifiers are free form, then what you are witnessing is the result of the creativity of human users. It is not a problem as long as the login identifiers are used for what they are. Spaces, semicolons... can wreck poorly implemented scripts or applications. (Try registering with an account name containing a single quote, in case there is some possible SQL injection.)

| improve this answer | |

Only the first email address is actually a valid address. Of course, email address validation is hard, so trying to implement perfect validation does not make sense. At a maximum, you can approximate validation, and for usability reasons, you should be lenient with your filter. Because of this, you should not base your security on the validity of email addresses.

Still, when you do require an email address for registration, it is customary to send a confirmation link to that address (to prevent typos, etc; not doing this may actually be considered a security issue), which would make your scenario impossible.

Either way, this is not a security issue. Your authentication should be able to cope with similar names, otherwise it's faulty.

I would however be careful with spaces at the beginning or end, as it happens quite often that it is trimmed off at some point, which may actually cause problems.

Other than that, there are only two small issue:

  • Typos: There may be a user test@example.com:123456 and a user test@example.co:123456. If one of them mistypes their credentials by accident, they may end up in the account of the other user. But this is quite a coincidence, and I wouldn't try to defend against it because of usability reasons.
  • Identification: You may display email addresses in place of usernames, possibly allowing a user to imitate a different user. Eg in your example test@test.com and test@test.com are difficult to distinguish. But this is again a corner-case, because usually, usernames are displayed for identification, not email addresses.
| improve this answer | |
  • Your link to that regex is dangerous for the eyes. – Turion Jan 28 '16 at 9:50
  • Email validation is hard if you have to roll your own. Since this is a website, there are plenty of libraries, frameworks, or whatevers that include email validation. They may also just be "close enough", but it alleviates the need to write your own validation logic making it substantially easier. – Ellesedil Jan 28 '16 at 21:31

All but the first should be rejected simply because they are not valid email addresses.

When you copy&paste them verbatim into your favorite email client they might do what you expect, but the most likely behavior is that it interprets them all the same. So if you want email addresses to uniquely identify users, you should insist on entering one (exactly one) syntactically correct email address on the registration form.

| improve this answer | |
  • You can't really reject all invalid email addresses upon registration, as email validation is quite complex, making perfect validation impractical. And instead of rejecting valid addresses, it is better to let through invalid ones. At most, you could send out confirmation codes to check if the address actually exists. But at that point, the user is already registered and their data stored in the db. – tim Jan 27 '16 at 21:58

There is definitely a security issue that stems from a provider allowing the registration of almost identical email addresses. But it's not quite the one that your specific examples are testing. And its effects aren't even necessarily limited to users of the email service, but can more broadly impact anyone receiving mail from a user that service. The danger I'm talking about is one that involves impersonation of a user of the service to mail recipients.

To see what I mean, let's first set aside the confounding issues (already well discussed) of what is and is not a valid mail address and whether a user's id is actually the same as the user's external email address. Instead, let's look at the following scenario:

Attacker wants to get malware implanted on Jane Smith's computer. Attacker knows Jane Smith's email address, knows that Jane Smith is close friends with John Anderson, and knows that John Anderson maintains an active email address with a webmail provider mail.com at JohnAnderson@mail.com. Attacker checks mail.com's registration process, and happily discovers that the service will allow him to register johnanderson@mail.com (no caps) as a valid address. Attacker sets his "from" name for the account as "John Anderson", and begins to compose a spearfishing email targeting Jane Smith. Attacker finds a PDF document on the internet that seems like the type of item that both John Anderson and Jane Smith might find mutually interesting, and then uses SET to insert into that document a PDF exploit and malicious payload.

Attacker sends the message. On Jane Smith's end, she receives an email from "John Anderson" at the address johnanderson@mail.com. The message is one forwarding on a PDF article with a one sentence recommendation from John: "Just finished this, and think you'll find it worth a read. Not sure I agree with all of the author's points, but very, very interesting." And because mail.com cryptographically certifies that the message does in fact come from the purported address, Jane Smith's email service has let the message go through to her inbox instead of kicking it to the spam folder (as might happen if Attacker just simply spoofed the "from" address).

Rhetorical question: what are the odds that Jane Smith opens that PDF attachment?

Answer: about as high as you're going to get for a spearfishing attack. (At least without gaining access to email system of her employer and impersonating her boss, or something along those lines.)

The chances that a typical user is going to realize that JohnAnderson@mail.com, johnanderson@mail.com, or even JAnderson@mail.com aren't the same sender are pretty low. (If the user is very security-aware in general, obviously the chances for detection go up. Though I suspect not as much as some might assume.) If the real email address of the real person that the attacker is trying to impersonate is already in the recipient's address book before the attacker's email arrives, the recipient might (might) when he/she receives the message notice that the sender of this particular message isn't in there, as the recipient would expect. And he or she might (might) find that a little suspicious. On the other hand, he or she will, more likely, just assume that the correspondent was emailing from a new, slightly-different address for some reason. Or that his/her email service's address book feature was being finicky. Or...

You get the point: This close-email-address impersonation tactic can be a very powerful (if sometimes overlooked) one in phishing/spearfishing attacks.

As to what email providers can do and are willing to do to try to bar very similar address registrations, it's a tough practice to effectively combat even if an email provider wants to. And considering that any given mail provider would prefer to tell registering potential users "Sorry, that address/user id is already taken." as few times as possible (if they get that message enough they might just give up and see if another email service one of their desired names free) the incentives for email services are to allow the registration of virtually any technically valid email address (with few exceptions).

| improve this answer | |

Agree with everyone else in stating that the first email address is the only valid one. Would also like to point out that it's a bad practice to allow for additional spaces at the end of a logon name. If I understand this correctly you're attempting to make the point of potential similarities in user/customer logons to the system.

So in answer to your question: "Should this be considered a security issue?" My answer would be, no, for any of the ones that did not contain additional spaces. Otherwise, yes...but mainly for the reason, below.

Your question; "Can anyone suggest any specific security issues that this setup could lead to?" Off the top of my head, while there are potentially a few more than I'm currently aware of, the only thing that I would consider is for some kind of a injection sort of issue. But that would come down to how the additional spaces are defined in your coding. If it's locked down well enough, there shouldn't be a problem. But then again, all sorts of techniques are being leveraged in ever changing ways. So nothing is truly ever completely secure. Thus one can only hope for and attempt to achieve better security.

| improve this answer | |

I develop Web applications for a living, and I can say this. While it may not be a "big" security risk, it certainly is sloppy development to allow someone to register with test@test.com; and/or 'test@test.com '.

Simply because the developer did not take the usually minimal time to add input validation. I mean even using plain HTML5, if you used an

<input type="email" />

and tried one of the second two email addresses the browser itself would show you an error saying "Not a valid email address (not tested at this point, but I certainly assume since HTML5 has been mainstream for some time).

But as the developer, you never allow someone to register with anything in their email, that should not be there. Such as *, &, ^, $, etc. It should (in my opinion) be a valid, alpha numeric email ending with an @something.com/net/org, etc.

It is very bad practice not to properly validate your forms input. Especially when this concerns potential client data, or customer data, student data and the like. It is very easy for spam bots or other forms of malicious bots/humans to find and sniff this flaw out and take advantage of the hole in the input process. For that, it may be a security risk.

Just my two cents though. Hope it helps.

| improve this answer | |
  • 5
    > never allow someone to register with anything in their email, that should not be there -- All of "*, &, ^, $" are valid in the local part of an email address. Then you're also rejecting IDN domain names, and all the new gTLDs. What if I have bob!@例.xyz? That's a valid domain (btw, it's available if anyone wants). And a valid email address. It has been discussed before: general consensus is that the best way to "validate" an email address is to attempt to send an email to it - if it gets through, the address is valid. Or use one of the proper compliant parsers. – Bob Jan 28 '16 at 5:40
  • So YOUR are responsibly for the websites that will net let me use my valid ".name" email address! – Ian Ringrose Jan 28 '16 at 15:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.