Auth case-sensitivity

I just spent time troubleshooting someone who was failing to log in. Finally realized that their tablet was making the first letter of their email capitalized when their account is all lowercase. Case-sensitivity was brought up already here:

I don’t know what we should do. We need to decide how to handle case. At the least, we probably should require more than case differences when requiring emails to be unique. I tested and was able to make two accounts with the same gmail just by using different capitalization…

If we don’t go to complete case-insensitivity, we should at least try to avoid the frustration of getting an email that just says the account doesn’t exist when people tried resetting with the wrong case.

Auth UX is complicated here because of differences between the email spec (RFC) and the way some popular providers handle emails.

For example, gmail drops all periods when deciding what mailbox to deliver to (so abc@, a.bc@, and ab.c@ are all treated the same). Should we do the same? What about trailing ‘+xyz’ type aliases?

I remember bookmarking an insightful blog post and Hacker News discussion about this a while back; I’ll look for it later and leave the link here when I find it.

I think an email should not be case sensitive any more than in other places. If I’m not mistaken it is almost never case sensitive. So if there isn’t a very strong reason for case sensitivity I’d drop it.

If there are email services which are case sensitive, then there is a strong security reason to be case sensitive.

Let’s pretend offers a case-sensitive email service, and you’re I can ask to reset the password for – a separate address I own, but that Snowdrift associates with the same account – and gain access to your account.

There is a way to avoid this particular vulnerability: convert all letters to lower case any time we send an email. However, it comes with the cost that two legitimately different people with emails like that can’t both have Snowdrift accounts.

In the case of capitalization, I think this is a pretty unlikely scenario, so it is worth the cost. However, in the case of periods being ignored, like gmail does, it’s a much harder decision, since most other email providers don’t ignore periods.

It also highlights that security is hard, and any change we make, especially UX changes that make things more convenient, must be given very careful thought first.

This is a situation where we need to prioritize matching industry standards over working from first principles. Whatever reputable organizations are doing, we should also do.

Does anyone have data on it? In my own experience, I haven’t really explored how sites treat case for email addresses.

That wouldn’t work for such cases. If someone legitimately had MRAY@ and wants to sign up, they simply couldn’t get an account at all even if mray@ never signed up. All attempts to register MRAY@ would get sent to mray@

A solution:

  • store case as entered for ident
  • use case-insensitive uniqueness test (do not allow mray@ and MRAY@ to both register accounts)
  • send all emails using the ident case
  • allow log-ins and resets to be case-insensitive

Thus, if mray@ exists and MRAY@ tries to log in, they’d still need the pass. But if MRAY@ tries to reset the pass, the email will go to mray@. Same in reverse. If MRAY@ registers, then mray@ will not be allowed to sign-up — but if mray@ tries a pass reset, the reset email will go to MRAY@ still as that is the ident originally registered.

I propose this as the solution. From everything I can think, this addresses any security and UX problems. The issue of not allowing two users with case-only-difference emails is unlikely to ever be a real issue.

I don’t have data from the sysadmin side really, but I searched around online and found that near-universal dominant approach is that emails are case-insensitive, and then the odd comment here and there of someone saying there really are two John Smiths at a business who have two emails that are different only in case. So, it seems that’s real and fits the spec, but almost all orgs ignore it.

I did also find it common (certainly not universal though) for the ID part of logins to be case-insensitive even when the ID is not an email address. (Obviously passphrases stay case-sensitive in all cases)

Yes, that’s the actual solution to this particular case (pun intended). I used “convert to lower case” in my example for brevity/understandability. The main point is that when it comes to auth, it’s easy to accidentally break security in search of good UX, so it’s important to take care.

In this case, I agree with Bryan. Email login is a super common use case. There are existing solutions that do this Right. Even if there isn’t a Haskell one that’s easy for us to set up, we can and should refer to other auth libraries, email providers, etc.

My experience is (and I did a test with my provider that matches it): capitalization plays no role. I can scream my mail address and it reaches me. Similarly I’m very familiar with people handing out their addresses in the format of – only to make it better to read. The idea that mail is case sensitive in the REAL WORLD is new to me.

So my conclusion is; Since this would be an issue with anybody sending mail to johndoe instead of JohnDoe – I think we are fine with excluding addresses that insist on capitalization.

1 Like

I think that settles it. We will do a case-insensitive match for email addresses. All other punctuation, etc will not be affected.


@chreekat How about my specific proposal? If someone registers with specific case, we still store whatever they enter and use that whenever we send email. But otherwise, all other things including log-in, pass reset request, and uniqueness-tests will all be case-insensitive?

Here’s a Hacker News discussion on the topic, with some junk comments and some good ones.

And yes, store-sensitive, dedupe-insensitive is the best solution in the case of capitalization.

1 Like

Sorry my response was terse, but yes, that’s what I meant to communicate. :slight_smile: We won’t change email addresses, only match against them case-insensitively. And like Stephen said, that goes for all situations where emails must be compared, including looking for duplicates.

1 Like

As this started with two issues in one topic, I split the outstanding one to a new topic.

I also edited the case-sensitivity code issue to have the precise specs.

I agree with this. Whatever case the user types in when registering, we should reproduce that to respect their preference, but we should not then allow another registration that is the same except for case, and we should allow them to log in regardless of case. I’m an example of a user who this would affect, since I prefer to use email addresses with Michael@ and MS@ rather than michael@ or ms@, but I use both and expect sites to accept both.

1 Like