TL;DR
Many applications are using email as user username. This blog post is about risk analysis for case insensitive emails used as application usernames.
Introduction
User management is core security feature for every application. Issue in that part of the application means game over for your customer privacy. First decision to be made is to decide how your application will uniquely identify application user. In order to set up vocabulary, I will call this feature username. Let’s check some industry leaders:
Github:
Github use username that user enters during the signup form, but also use email.
Atlassian:
Atlassian use only email.
Facebook:
Facebook use email or phone.
Using email in sign up is handy, because you can use email address for account verification.
Risk Analysis
When you use email as username, you need to conform to Simple Mail Transfer Protocol standard. That means that allowed values for username in your application are strictly defined. What could go wrong with email as username that is not case sensitive? Let’s check what standard has to say about case sensitive emails:
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.
So, part left from @ is case sensitive, while right part, or domain name, is not. Here are some examples:
karlo@testival.eu is same email as karlo@Testival.eu, but Karlo@testival.eu is different email. Gmail is different kind of beast, because they override that standard. In gmail, you can not have case sensitive username part of email, is somebody else is already using that username in case insensitive form (you can try this experiment with your gmail account). They own gmail domain which is preset to gmail value:
But gmail is industry leader, and if you want case sensitive username, good luck with other email vendors 🙂
What is risk with case sensitive email? Log in form is first user interaction with your applications. User use your application not because of its security feature, log in form, they want to do actual work with the app. Users do not care about hackers, for them, login form is obstacle. Soon, they will request that both case insensitive email and original email are both accepted as usernames.
If they do not use gmail but other email providers, those providers will comply with RFC SMTP standard that allows case sensitive emails. And in that case, you will not be able to satisfy that feature request because of following risk:
It is possible that there will be existing case INSENSITIVE version of user case SENSITIVE email and this will break username uniqueness requirement.
Conclusion
When you make design decision, be aware of standards that go with those decisions.
