Opened 17 years ago
Closed 16 years ago
#5472 closed enhancement (fixed)
Case insensitive usernames
Reported by: | mdawaffe | Owned by: | 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:
- 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.
- Fewer users who forget their usernames.
Cons:
- 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:
- Removes artificial, case sensitive check.
Other Options:
- 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.
- 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)
Change History (14)
#2
@
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:
↓ 4
@
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
@
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
@
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
@
16 years ago
nailed this down to MySQL:
mysql> select 'Admin' = 'admin'; +-------------------+ | 'Admin' = 'admin' | +-------------------+ | 1 | +-------------------+ 1 row in set (0.00 sec)
+1 to this patch. Minor, if no, security loss while making it easier for users to login.