Password Reset Form Improved Error Messages

[mrtortai]

On the WordPress Lost Your Password form (/wp-login.php?action=lostpassword):

If you enter an incorrect username the following message will display: "ERROR: Invalid username or e-mail."
And if you enter an incorrect email address, the following message will display: "ERROR: There is no user registered with that email address."

These error messages provide helpful information to an attacker or automated bot or spammers by helping them determine correct usernames and email addresses.

For an alternative approach, we can look at Apple, Namecheap, Cloudflare, for example:

Apple:
​https://iforgot.apple.com/password/verify/appleid
Enter any incorrect Apple ID. The value can be accepted and the form provides no indication that the Apple ID is incorrect.

Namecheap:
​https://manage.www.namecheap.com/myaccount/rememberpwd.asp
Enter an incorrect username or email address.
Nondescript Message: "If your email address exists in our database, you will receive a password recovery link at your email address in a few minutes!"

Cloudflare:
​https://www.cloudflare.com/forgot-password
Enter an incorrect email address.
Nondescript Message: "If an account with this email exists in the system you will receive an email confirmation shortly."

Suggestions:

The WordPress Lost Your Password form should not provide any indication if the username or email address entered is correct or incorrect.

[mrtortai]

Patch 31787.patch

[michaelbeil]

This seems like a good change. Have you tested it?

[mrtortai]

I have tested. Requires more testing :-)

[MikeHansenMe]

There have been a number of related tickets. Ultimately the decision has always been the username is not a secret.

@ipstenu has a great article on it as well as Otto's comment.

​http://halfelf.org/2014/username-secret/

[MikeHansenMe]

Didn't mean to update all the other stuff. Just leave a comment.

[mrtortai]

Agreed 100% with Otto. Username is not a secret.
However, security requires many layers I think.

[voldemortensen]

The decision to leave this alone has been made many many times as shown in the following tickets.

Related, duplicate: #3708, #4290, #5301, #12129, #22421

[jorbin]

Thanks for the report mrtortai. As is pointed out above, this is by design. We need to balance user friendliness with information disclosure and as usernames are not considered private information ( the article on halfelf.org linked above does a decent job of explaining this), user friendliness wins here.

In the future, if you have what you would consider a security issue, I would encourage you to first email security@… before creating a trac ticket.

[mrtortai]

Hello,

I think it is worth reopening this discussion IMHO.

The best explanations for why this is by design was from @markjaquith (https://core.trac.wordpress.org/ticket/3708#comment:3) which was from 8 years ago! Most duplicate tickets have been closed only because other prior tickets have been closed.

If the usability/security balance is successful with Apple, Namecheap, Cloudflare, etc I think this is worth a discussion and a re-evaluation.

Hi @jorbin, I don't believe this is a security bug which warrants it being posted to security@….

I am leaving this as closed to defer to @voldemortensen, however, I would encourage a re-evaluation on this topic.

[Ipstenu]

The security/usability balance between a company and its users and a self-hosted software and it's users is a little different. If I get locked out of namecheap because I can't remember my email or username, I can still contact them for help.

If I can't get into my own site, who do I turn to?

It's an unnecessary roadblock for the majority.

(Google's gmail says "No account found with that email address." by the way)

[voldemortensen]

For the sake of argument, let's say we change the error message to say something else. It would take any decent bot an extremely negligible amount of time to determine usernames from either the urls, as @mark mentioned, or the use of an enumeration tool, or any of the other ways usernames are available. I do think that security through obscurity is helpful in some areas, but this change wouldn't slow down anyone with malicious intent.

[johnjamesjacoby]

I like the idea of modifying this verbiage to be less revealing. I agree there is a balance between helpfulness and obfuscation, but the internet is a bit older than it was when this phraseology was decided upon, and (I hope) our average user is a bit wiser than (we all were) back then.

We don't need to completely lose WordPress's helpful personality, but I don't think it's a necessarily a great idea for the default experience to be to provide helpful hints at guessing ones way into the system.

If I can't get into my own site, who do I turn to?

You turn to the software you rely on to power your website. Simply request to reset your password, and it will send an email to the address you provided. If you no longer have access to that email address, you likely have other problems.

Username is not a secret.

WordPress conveniently separates the duties of logins and author slugs into user_login and user_nicename columns in the database. Our canned response has always been "nice-names & logins are not customizable" and while accurate, I think it's also not ideal.

The reality is there is little harm in allowing users to modify their logins or slugs, and the code to introduce this functionality into WordPress core is relatively trivial. Other considerations might be:

• Login with email instead (one great plugin does this really well)
• Limit the number of login & nicename changes (default to 1?)
• Two factor magic-link style logins in core
• Plugins like BuddyPress & bbPress that provide literal profile pages using the nicename
• Existing plugins for modifying author archive & user slugs

The stance has always been that these are plugin territory, and I agree that they always have been, but I'm proposing that maybe they shouldn't always be going forward, and we should look for ways to modernize this area of WordPress.

[SergeyBiryukov]

Replying to johnjamesjacoby:

The reality is there is little harm in allowing users to modify their logins or slugs, and the code to introduce this functionality into WordPress core is relatively trivial.

Related: #14644

[Ipstenu]

You know that's noT what happens, JJJ. If someone can't log in to their website, they call their web host. Because we're also talking about what error do you get when you use that reset feature. If they get the error that there's no user with that email when trying to log in, they'll get the same when trying to reset, but at least they know what is wrong.

I think the helpfulness of a clear 'this is what's wrong' is more important for the user experience when they are their own tech support and, for many of them, it's exceptionally difficult for them to be that. Unless we can make that bar low enough to guide the, back in, we will be locking people out of their own sites. Password recovery, when you've forgotten your email or username, seems to many of us to be fairly extreme, but for someone who doesn't log in more than once a month at best, it would be crippling.