WordPress.org

Make WordPress Core

Opened 13 years ago

Closed 13 years ago

Last modified 9 months ago

#3708 closed defect (bug) (wontfix)

wp_login is too "friendly" -- Information disclosure

Reported by: charleshooper Owned by:
Milestone: Priority: low
Severity: trivial Version: 2.2
Component: Security Keywords: security login has-patch
Focuses: Cc:
PR Number:

Description

While it's not exactly the end of the world, if you attempt to login with an invalid username the error message returned is actually "Invalid username." Obviously it works as intended; However, I consider this information disclosure and feel that invalid usernames and passwords should both return the same error message.

Attachments (1)

wp_login.diff (961 bytes) - added by charleshooper 13 years ago.
"Fix" for ticket #3708

Download all attachments as: .zip

Change History (16)

@charleshooper
13 years ago

"Fix" for ticket #3708

#1 @charleshooper
13 years ago

  • Keywords has-patch added; error removed

#2 @charleshooper
13 years ago

  • Milestone changed from 2.3 to 2.2
  • Version set to 2.2

#3 @markjaquith
13 years ago

There are other ways to verify user names. You can reverse engineer them from the author archive URLs (e.g. http://example.com/author/mark/). I believe the consensus last time this came up was that it was trivial to figure out the user names anyway, and that it is much more user-friendly to tell them when they messed up their username, and not the password. Also, "admin" is created on install, and can't be changed using WordPress itself, so there's no hiding that.

#4 @charleshooper
13 years ago

  • Resolution set to wontfix
  • Status changed from new to closed

Good point about the author archives, I hadn't really thought about that. Guess I was just excited about submitting my first patch for Wordpress, even IF it was only to change some error messages.

But now that I've been reminded that there are many other ways to get valid Wordpress usernames (that are all quite a bit easier than brute forcing the login) it just doesn't make sense to leave this ticket hanging.

#5 @foolswisdom
13 years ago

  • Milestone 2.2 deleted

#6 @SergeyBiryukov
7 years ago

#22421 was marked as a duplicate.

#7 @helen
6 years ago

#27125 was marked as a duplicate.

This ticket was mentioned in Slack in #forums by dmchale. View the logs.


5 years ago

This ticket was mentioned in Slack in #core by dmchale. View the logs.


5 years ago

#10 @voldemortensen
5 years ago

#31787 was marked as a duplicate.

This ticket was mentioned in Slack in #core by swissspidy. View the logs.


3 years ago

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


2 years ago

#13 @ocean90
13 months ago

#45318 was marked as a duplicate.

#14 @earnjam
13 months ago

#45318 was marked as a duplicate.

#15 @afercia
9 months ago

In 44918:

Accessibility: Login: Display error messages when both the username and password fields are empty.

For accessibility and usability, if an input error is detected, the item that is in error needs to be identified and the error needs to be described to the user in text (WCAG Success Criterion 3.3.1). The login form displays an error when the username field is empty or when the password field is empty. It omits to do so when both fields are empty.

This change restores the login form behavior to the one that used to work in WordPress 2.3 (!) and displays the related error messages also when both fields are empty.

Props birgire, audrasjb.
See #8938, #5405, #3708.
Fixes #42985.

Note: See TracTickets for help on using tickets.