Generic login failure message

[scohoust]

I'm happy to be told that this is not important but something I felt like mentioning. Take a common web application and get your password wrong - very often you'll be told the username/password combination is wrong (and not specifically your password).

WordPress doesn't do this, instead it will tell simply tell you that the password is wrong. Helpful perhaps to the user but also a bit of a security issue?

Patch changes the message to not differentiate between a correct or incorrect username.

[ryan]

This is by design. There is a balance to be made between security and user friendliness.

[prionkor]

Replying to ryan:

This is by design. There is a balance to be made between security and user friendliness.

If that's true Most (if not all) user web apps today lacks that's kinds of user friendliness. Fixing this will also resolve a security issue. Also user who have little experience on the web they expects that they wont get any kinds of info about which one (username/password) is wrong as their experience. So, it doesn't make wordpress less user friendly.

Wordpress password reset also allows user to reset password by username or email. So, if someone also forgets there username they can surely reset and confirm via email address.

It could be another option to have a checkbox on settings where admin can disable the generic error if required.

[bobbingwide]

Should this be revisited in light of the current scare?

[SergeyBiryukov]

Related: #24078

[lumpysimon]

Replying to bobbingwide:

Should this be revisited in light of the current scare?

The current scare is about a massive automated attack, changing the error message won't make any difference to that.

However, I do think a generic message is a positive, if small, security enhancement against individual attacks. I currently implement it on all my clients' sites via the login_errors filter and have no reports of users being negatively affected by it.

[Otto42]

Negative, and I would leave this as wontfix.

The simple fact is that no real automated attacks use this information. My sites don't have an admin user at all, and the no-such-user message is there for anybody to see. But the bots are stupid and keep hammering away at it.

Getting a username from elsewhere in the site is trivial. Changing this message to generic adds no security against bots (because they ignore it anyway) and no security against real people (who can find the actual username trivially).

+1 to real-user-friendliness instead.

[MikeHansenMe]

As mentioned by Ipstenu in her blog post​http://helf.us/tp, there are other ways to find a username. +1 for wontfix.

[Ipstenu]

+1 for wontfix

Your login ID is not a secret (as Nacin eloquently pointed out on -hackers today).

[bobbingwide]

OK. Given that there are numerous filters and actions I'm happy to close this with the following remarks.

If you want to alter the text of the message produced for "invalid_username" or "incorrect_password" then you can implement a filter for "login_errors", replacing the passed in message with your own.

Note: With the current implementation, you will need to determine the error from global $errors.

add_filter( 'login_errors', 'fob_login_errors' );
function fob_login_errors( $message ) {
  global $errors;
  if ( isset( $errors->errors['invalid_username'] ) || isset( $errors->errors['incorrect_password'] ) ) {
    $message = sprintf( 'Invalid username/password combination.<br><a href="%1$s" title="%2$s">%3$s</a>?'
                      , site_url( 'wp-login.php?action=lostpassword', 'login' )
                      , 'Request a new password'
                      , 'Lost Password'
                      );
  }
  return $message;
}

Alternatively, implement the 'authenticate' filter to return null when there's a WP_error in $user.e.g.

add_filter( "authenticate", "fob_authenticate", 100, 3 );
function fob_authenticate( $user=null, $username=null, $pass=null) {
  if ( is_wp_error($user) ) {
    $user = null;
  }
  return( $user );
}

wp_authenticate will then create an 'authentication_failed' message with the required text, but with side effects that both fields are blanked out and there's no shaking (until 'authentication_failed' is added to $shake_error_codes).