Make WordPress Core

Opened 17 years ago

Closed 16 years ago

#5472 closed enhancement (fixed)

Case insensitive usernames

Reported by: mdawaffe's profile mdawaffe Owned by: denis-de-bernardy's profile Denis-de-Bernardy
Milestone: 2.8 Priority: normal
Severity: normal Version: 2.5
Component: Users Keywords: has-patch tested commit
Focuses: Cc:

Description

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?

Attachments (2)

5472.diff (416 bytes) - added by mdawaffe 17 years ago.
5472.2.diff (562 bytes) - added by Denis-de-Bernardy 16 years ago.

Download all attachments as: .zip

Change History (14)

@mdawaffe
17 years ago

#1 @Viper007Bond
17 years ago

  • Version set to 2.4

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

#2 @DD32
17 years ago

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.

#3 follow-up: @matt
17 years ago

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

#4 in reply to: ↑ 3 @DD32
17 years ago

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'

#5 @Denis-de-Bernardy
16 years ago

  • Component changed from General to Users
  • Owner anonymous deleted

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

#6 @Denis-de-Bernardy
16 years ago

nailed this down to MySQL:

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

#7 @Denis-de-Bernardy
16 years ago

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.

#8 @Denis-de-Bernardy
16 years ago

  • Keywords tested commit added
  • Milestone changed from 2.9 to 2.8

#9 @Denis-de-Bernardy
16 years ago

possibly related bug: #5918

#10 @Denis-de-Bernardy
16 years ago

  • Owner set to Denis-de-Bernardy
  • Status changed from new to accepted

#11 @peaceablewhale
16 years ago

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

#12 @ryan
16 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed
Note: See TracTickets for help on using tickets.