Handling of capital letters in account's email address

[Gummikavalier]

Description:

Email standard ignores difference between upper and lowercase letters in the email address format. (Case insensitive by design.)

However, Rocket.Chat email address attribute content is handled as case sensitive.

This causes issues when RC is supposed to merge two Oauth/OpenID accounts of the same user from two separate authentication sources. Those users who have their email address in both authentication sources exactly the same end up having one account, while those having one in upper and other in lowercase will have two separate accounts. (As long as the OpenID provided username is different, and it often is.)

Steps to reproduce:

1. Create separate accounts on two Oauth/OpenID authentication sources: testuser and testuser2.
2. In one authentication source set the email addess as test.user@example.com and in other Test.User@example.com.
3. Log in to Rocket.Chat with both accounts in succession.

Expected behavior:

Only the first account testuser gets created. Logging in with the second account testuser2 should still get in, at least after the proper email verification. Accounts get merged, although the latter username gets embedded into the former in the database and is not visible to the user.
One user account for one real working email address makes user and channel management easier.

Actual behavior:

Merge does not happen. Rocket.Chat generates two visibly and in reality separate accounts for those users whose emails are not uniform:

testuser, email: test.user@example.com
testuser2, email: Test.User@example.com

Naturally those that get two separate user accounts in RC are handled completely separately by RC in channel membership selections etc. causing confusion.

Now, both behaviors would be ok; one merged account when emails are 1:1, or always two accounts. Latter would be ok only if it was predictably consistent. But they are not; some authentication sources allow users to type in the email addresses as they see fit (bad), some reformat them to lowercase in all situations (good), and others generate the email addresses directly from the givenname and surname, including their capitals (bad).

Because RC instance admin is not responsible for maintaining all possible federated authentication data sources of users, some of the users end up having one account in RC, and others get several, just because their email address format is not uniform across the board. (And I emphasize again that email standard itself handles all email addresses case insensitively regardless.)

Therefore I suggest that all email address attribute data should be converted to lowercase by RC itself, or at least they should be internally handled as lowercase.

Server Setup Information:

• Version of Rocket.Chat Server: 3.16.3
• Operating System: CentOS7
• Deployment Method: tar
• Number of Running Instances: 2
• DB Replicaset Oplog: Yes
• NodeJS Version: 12.22.1
• MongoDB Version: 4.0

Additional information:

From security point several accounts or one account for one email address does not cause an issue; one still cannot forge and seize accounts with wrong email addresses as long as accounts are email verified. User confirms they are in hold of the email address (and thus account) in the account creation process and that can always go only to one DNS MX email record owning recipient, no matter whether upper or lowercase email address was provided.

[debdutdeb]

Hi Gummikavalier, thanks for reporting this.

some authentication sources allow users to type in the email addresses as they see fit

Can you give me an example so that I could reproduce this?

In the meantime I'll look into the source and try to pin it down.

[Gummikavalier]

Hi! Regarding authentication sources this is slightly theoretical. But it is common in Finland for instance that lots of people use email addresses provided by internet operators, and when they change to other operator, also their email address changes. So users end up updating their profiles in all kinds of services and locations, bringing human error into play. When federation services bring more and more authentication providers to their service, so does the risk of any of the providers not stylizing their inputs (of course a good question should such provider be allowed into the federation in the first place).

Open.rocket.chat is slightly in the position like that as it allows users to authenticate via GitHub, GitLab and Google, or all of them. In theory it might be possible to add new email address to some of these big authentication providers with my current address but only in uppercase. But these experienced providers are quite likely to stylize their email fields to lowercase when saving them. (And indeed at least GitHub does not let me add the same email directly in uppercase as it considers it being the same as the already existing lowercase one.)

We actually are having the uppercase/lowercase issue in our company. We have two Custom Oauth providers in RC. One of the auth sources will always provide email address to RC in lowercase and is fine. But the other has decades old accounts whose email addresses are partly in lowercase and partly in uppercase in pretty random fashion. On our RC these partly uppercase email addresses are now generating two completely separate accounts for their respective users instead of merging them.

The troublesome authentication source maintainers have simply stated it is not viable at this point anymore to change the format syntax to all lowercase, because the accounts exist in large variety of other systems. Should the email address be altered in the source, some of those systems could simply generate new accounts in the very same manner as RC is doing now, or just simply fail to log in.

[debdutdeb]

Hmm alright. Sounds like a logical ask. I'll talk to our product manager. Thanks for bringing this up Gummikavalier!

[Gummikavalier]

Thanks debdutdeb! 👍

[photoninger]

This affects also federation when you are searching for external users.
It is not user-friendly to type in the exact case-sensitive email address in order to find users on external servers.

rocket.chat Server Version: 4.3.3

[Gummikavalier]

We looked into this issue again in RC 4.5.3. The outcome was that the bug might be in the part that does the merge function.

When we create (via login with OIDC/Oauth) an account that has the email test.account@example.com
and then log in with a similar account that has email Test.Account@example.com
the result is that the latter account gets merged to the previous account.

BUT if we first log in with an account that has the email Test.Account@example.com
and then log in with the account that has the email test.account@example.com
the result is that the latter one does not get merged to the previous account. A new account gets created instead.

We assume that the bug would be:

The part of the code that does the initial creation of the account does not decapitalize the email address at all. It writes up what was got from OIDC endpoint.

However, the merge operation does decapitalization. But it does it blindly, and does not compare whether the original account was in upper case to begin with and ends up creating a new account as lower case email account does not yet exist.

Possible fix would be to enforce lower case of email in all use situations.

[looeee]

Possible fix would be to enforce lower case of email in all use situations.

This makes sense to me. I ran into this issue. I'm using Keycloak and I was not able to edit the capitalised email in Rocketchat as it sees the edit it as a duplicate of the non-capitalised email.

I thought of editing it in keycloak to have the capital letter, however, keycloak does not allow emails with capital letters.

In the end the workaround I found was to delete the oauth user from rocket chat, then set both emails to an identical fake address (fake@example.com), then log in with keycloak so the accounts are merged, then change the merged email back to the correct email in both keycloak and rocket chat.

This was kind of painful though and I guess would be much harder on another oauth system where I did not have access to changing the user email account.

[Gummikavalier]

Indeed. As the email is case insensitive protocol at least in email address syntax, RC should operate the same way in all situations.

We actually had a support ticket about this a year ago that had gone missing. I opened a new one, as I tested this is still an issue in our use case with two separate Oauth providers.

[Gummikavalier]

🥳 ❤️

[Gummikavalier]

Thanks! The fix was released in RC 5.3.1 and I tested it now.

I confirm that the issue is fixed when using email as the keyfield in two separate oauth configs.

For the record the issue still happens when the username is used as the keyfield. What I mean by this is that it still is not consistent; should the capital account having capital email get created before the other, the merge does not happen, but other way around it does.

I'm not sure if this latter scenario matters much though; RC is email validated and depends so much on email in so many of its features that it is probably best to use email as the keyfield anyway.
Even had the username keyfield-scenario been fixed, another account having the same email would still be able to seize the original account just because all the password reset etc. features rely on email and email flows regardless of capital letters always to the same recipient.

Email as the validation for username can be a security issue, but it is that only chronologically in long term; lots of users in the system and someone with the same name is eventually bound to get a recycled email address from someone else.
This type of problem simply has to be addressed by other means than in RC.

[looeee]

For the record the issue still happens when the username is used as the keyfield.

So to clarify, if I have set up my org with Keycoak login style username, password instead of email, password, this is still an issue?