search

PeerSay / Atlas

The PeerSay MVP project
0 stars 0 forks source link

User's email address in the login process is evaluated case-sensitive #144

Open talbendavid opened 9 years ago

talbendavid commented 9 years ago

The user email used for login is evaluated case-sensitive. For example - a user registered as Admin@peer-say.com failed to login as admin@peer-say.com

Email addresses are not case-sensitive and should be accepted in login regardless of case.

Pavek commented 9 years ago

We need to debate it. Here's some useful links: http://stackoverflow.com/questions/9807909/are-email-addresses-case-sensitive http://email.about.com/od/emailbehindthescenes/f/email_case_sens.htm https://en.wikipedia.org/wiki/Email_address

Quote from wiki:

The local-part postmaster is treated specially–it is case-insensitive, and should be forwarded to the domain email administrator. Technically all other local-parts are case-sensitive, therefore jsmith@example.com and JSmith@example.com specify different mailboxes; however, many organizations treat uppercase and lowercase letters as equivalent.

One more:

According to RFC 5321 2.3.11 Mailbox and Address, "...the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address.". This means that no assumptions can be made about the meaning of the local-part of another mail server. It is entirely up to the configuration of the mail server.

RFC 5321, the standard that defines how email transport works, lays down the email address case sensitivity issue thus:

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.

The part after the @ sign however is the domain and according to RFC 1035, section 3.1,

"Name servers and resolvers must compare [domains] in a case-insensitive manner"

So, technically, the addresses:

But practically they are all the same, most likely.

So, here's the proposed solution:

talbendavid commented 9 years ago

A very thorough analysis. The bottom line is correct - should be treated as case-insensitive.

I don't think there is any point in stating this explicitly anywhere until we have a Support site to host such a topic.

With regards to the solution - it is ok. But here's another potential solution (I tried to research it a bit today without success): Maybe the passport library can be given an authentication strategy that ignores the username case.

If this option exists, then it does not delegate the issue to mongoDB and may be ok perfromance-wise. Do you know if this is available?

Tal

Tal Ben-David, _CEO & Co-_Founder +972.52.4739064

On Thu, Jul 23, 2015 at 5:51 PM, Pavel Zhytko notifications@github.com wrote:

We need to debate it. Here's some useful links:

http://stackoverflow.com/questions/9807909/are-email-addresses-case-sensitive http://email.about.com/od/emailbehindthescenes/f/email_case_sens.htm https://en.wikipedia.org/wiki/Email_address

Quote from wiki:

The local-part postmaster is treated specially–it is case-insensitive, and should be forwarded to the domain email administrator. Technically all other local-parts are case-sensitive, therefore jsmith@example.com jsmith@example.com and JSmith@example.com JSmith@example.com specify different mailboxes; however, many organizations treat uppercase and lowercase letters as equivalent.

One more:

According to RFC 5321 2.3.11 Mailbox and Address, "...the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address.". This means that no assumptions can be made about the meaning of the local-part of another mail server. It is entirely up to the configuration of the mail server.

RFC 5321, the standard that defines how email transport works, lays down the email address case sensitivity issue thus:

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.

The part after the @ sign however is the domain and according to RFC 1035, section 3.1,

"Name servers and resolvers must compare [domains] in a case-insensitive manner"

So, technically, the addresses:

  • Admin@domain.com Admin@domain.com and admin@domain.com admin@domain.com -- are different and depend how domain.com treats them
  • admin@domain.Com admin@domain.Com and admin@DOMAIN.com admin@DOMAIN.com -- are the same

But practically they are all the same, most likely.

So, here's the proposed solution:

  • treat all email addresses as case-insesitive (and explicitly state that mail servers that treat them otherwise are not supported, because this behavior, albeit allowed, is discouraged by RFC 5321)
  • normalize all emails stored in DB to lowercase
  • update registration logic to save to DB in lowercase only (That is, to avoid performace porblems described here: http://stackoverflow.com/questions/7101703/how-do-i-make-case-insensitive-queries-on-mongodb )
  • update login logic to compare submitted address in lowercase

— Reply to this email directly or view it on GitHub https://github.com/PeerSay/Atlas/issues/144#issuecomment-124130477.

Pavek commented 9 years ago

Passport 'local' strategy hardly can help -- it is very slim and delegates all authentication/DB logic to our code.

talbendavid commented 9 years ago

I see. So let's go with your proposal.

בתאריך יום ו׳, 24 ביולי 2015 ב-16:40 מאת Pavel Zhytko < notifications@github.com>:

Passport 'local' strategy hardly can help -- it is very slim and delegates all authentication/DB logic to our code.

— Reply to this email directly or view it on GitHub https://github.com/PeerSay/Atlas/issues/144#issuecomment-124523670.