Case insensitive usernames

[mdawaffe]

We currently store usernames case insensitively (the default collations for MySQL are case insensitive).

When we check to see if a username already exists, we do so case insensitively (for the same reason).

When users log in, we require them to input there username case sensitively (there is an artificial, case sensitive check during login to ensure the supplied user name is the same as the username stored in the DB).

Why the inconsistency? Why not let users type in their usernames case insensitively?

Pros:

1. Frontend consistency with backend. All aspects of username case (in)sensitivity would be controlled by the collation on the user_login column of the users table.
2. Fewer users who forget their usernames.

Cons:

1. Easier for "the bad guys" to fish for usernames. The party line seems to be that it's easy to do that anyway, though.

Attached:

1. Removes artificial, case sensitive check.

Other Options:

1. The other way to remove inconsistency would be to be case sensitive everywhere. We could alter the user_login column to varbinary or do user_login SELECTs with the BINARY operator. There may be problems with that idea, though, coming from differences is charsets between different operating systems (or even browsers?). Especially if you move your DB from one host to another.
2. Keep as is. WP 2.3.1 incorrectly reports "incorrect password" after a login attempt with a incorrectly cased username. WP trunk reports the correct error: "incorrect username", so at least we're now giving the user the correct feedback.

Opinions?

+1 to this patch. Minor, if no, security loss while making it easier for users to login.

See also #2244, However that was simply to change the error message.

+1 to consistancy though, dd32 and DD32 are the same user, Theres no reason different capitalisation should prevent me logging in.

My tables all seem to default to utf8_general_ci, which appears to still reject non-matching-case logins even with this patch.

Replying to matt:

My tables all seem to default to utf8_general_ci, which appears to still reject non-matching-case logins even with this patch.

Cannot reproduce on Trunk w/ utf8_general_ci tables. After applying the patch, logging in with 'dd32' logged me in as 'DD32'

confirmed in 11256. cannot create an Admin user when admin exists, and cannot log in as Admin in place of admin.

nailed this down to MySQL:

mysql> select 'Admin' = 'admin';
+-------------------+
| 'Admin' = 'admin' |
+-------------------+
|                 1 | 
+-------------------+
1 row in set (0.00 sec)

then tracked this down to wp_authenticate_username_password(). It finds the "correct" user due to the above issue in MySQL, but ends up rejecting it because php considered the above to be false.

mdawaffe's patch (refreshed accordingly) fixes things indeed.

possibly related bug: #5918

I am able to login with "AdMIn" after applying 5472.2.diff.

[11397]