Security problem: Login Oracle

[d0rkpress]

Hello,

when logging in to WordPress one can tell from the error message whether the user account exists or not. It's either "ERROR: The password you entered for the username <USERNAME> is incorrect" or "ERROR: Invalid username".

This is basically missing the 101 security requirement of a login, see ​https://www.owasp.org/index.php/Authentication_Cheat_Sheet#Incorrect_Response_Examples.

Yes, I read that: ​https://make.wordpress.org/core/handbook/testing/reporting-security-vulnerabilities/#why-are-disclosures-of-usernames-or-user-ids-not-a-security-issue . But it in 2018 it is time to change this. You need just to look into any logfile of any webserver you will find lots of probes for the WordPress login.

The threat is that it is minimizing for an attacker considerably the effort by a 2 x square root factor. Let's say in 1000 user accounts I have one hit on a web site, for a password guess I have another 1 in 1000 hits. Without a login oracle I would need 1000^2 tries to get a hold of a login. With this oracle I need 1000 + 10000 tries. One million requests vs. 2000 makes a huge difference.

Please

Thanks, Dirk (OWASP guy, Pentester, Consultant, IT Security >20yrs professional experience)

[SergeyBiryukov]

Hi @d0rkpress, welcome to WordPress Trac! Thanks for the report.

Just noting this has been previously reported a few times, most recently in #40667.

As stated in the ​handbook article you've linked to, we don't consider usernames (and by extension, the existence of accounts) to be private. A similar thing can be achieved just by browsing the /author/{slug} views.

We need to balance user friendliness with information disclosure and as ​usernames are not considered private information, user friendliness wins here.

Please don't ignore the warning that Trac displays when creating security tickets. If you believe you've found a vulnerability, please ​disclose it to us privately, ​via HackerOne.

Related: #3708, #4290, #5301, #12129, #22421, #27125, #31787, #40667.

[d0rkpress]

Thanks .

If you're interested in making Wordpress more secure you should follow security best practices and arrive in 2018. I am doing pentests for an eternity and everybody since a long time gets slapped (not literally) who does not meet such a basic security requirement. It's to my statistics reaaaally seldom the past years I see such a login message.

To cite the link from Half-Elf:

"WordPress is not alone in thinking your username isn’t a secret. Drupal also thinks disclosure of usernames/id is not a security risk. "

What a -- sorry -- stupid excuse. Only because my neighbor does something which sounds for an average person absurd, I should give up thinking and just do the same?? Please use your own intelligence and don't rely on others.

"In fact, Google doesn’t think your ID is a secret"

Yes but
A) They have not really choice as their services are bound to the e-mail address. You do!
B) Go ahead and try to brute force a login at Google. You won't be able to do so. Google (as Twitter and others) have arrived in 2018 and do a great job of fraud detection or anti-automation measures on authentication functions. Out of the box Wordpress doesn't come with those things.
C) For Google services it's even a no-brainer to switch on MFA. For Wordpress out of the box I do not even have a choice.

So, please stop this nonsense comparisons.

"user friendliness wins here.". As said, it's 2018. People use browsers which store usernames or have external password management systems which could include usernames. There is no advantage to signal those things with a verbose error message like this to an average user. There might be one to people starting using the computer a year ago but if that is the audience where you adjust your security posture to: good luck!

WRT HackerOne: This is a bug which doesn't fall in the categories HackerOne is accepting. But it is a security bug, so the only choice to me was posting it here. (This is a general question which you might want to address)

The question to me boils down whether you are willing to take security seriously in 2018 or not and stick to what was labeled as user friendly 15 years ago.

[ocean90]

Duplicate of #3708.

WordPress takes security and user experience very seriously, no matter what year it is.

[d0rkpress]

WordPress takes security and user experience very seriously, no matter what year it is.

by closing it that fast (within 10 minutes) I heavily doubt the former

[d0rkpress]

Oh, jeez... The first bug filed on this is twelve years old and you're still doing the same -- security-wise.

[knutsp]

The fact that WordPress usernames practically are public means that changing the login messages are futile at this point.

Instead of sarcasms, start arguing why WordPress should migrate to regarding usernames as secrets, in addition to the passwords.

The current behaviour is that the database row ´user_nicename´, which is used as slug (URL component) in author archives are constructed from the username (user_login) itself. Also usernames cannot be changed. (But all of this can and are changed by plugins.) Include: How could this change and why should we bother?

Example pro argument: If a weak password is guessed then it's even easier to get in if the username is detectable.

Example contra arguments: When passwords are leaked both username and password will be leaked anyway; requiring https is better; and extra character in the password is better; and so on.

Please respect that the matter has been discussed many times before. Include whatever new facts that was not known when the matter was discussed last time. Be constructive.

[d0rkpress]

The fact that WordPress usernames practically are public means that changing the login messages are futile at this point.

As said this is a bad idea from the security standpoint. It has been 12 years ago as the first bug was file in this matter. And IMO it's not futile. Start with something. Then move on. I have to confess that I knew the other places before, not this one. Mostly because peers and customers of mine are having additional measures in place anyway at the login.

Instead of sarcasms, start arguing why WordPress should migrate to regarding usernames as secrets, in addition to the passwords.

Forgive my sarcasm but to me it is that obvious that the whole world seems to know this is not any good -- except Wordpress who refuse to acknowledge this. Others in this thread were not even considering this and just closing it without consideration. So thanks for getting back to me.

The most important argument is above in pure technical means -- forget for now about the other places which allows user name enumeration, let's do a step by step approach.

Again I am try to outline this time more easily what I filed initially. This is the classical approach....

Suppose I am am attacker. I have a laaarge dictionary of potential user names. I also have a dictionary of passwords. If I feed them to my favorite tool both user name and password need to match for being successful. That is quite a challenge.

The step by step approach which I can do at wordpress logins is way better for me. I just feed first my fav tool with user names and grep for the string "is incorrect". Let's say after 7200 tries I am successful. If I can submit 4 requests per second and the server answers in the same time it I have the first username in 7200/4=1800 seconds, equals 30 minutes.

Next step is to find a password. I have this cool dictionary with passwords. Now I use the username and feed the list of passwords into my tool. Let's say I need 7200 tries here to guess the user name.

Thus I needed in total 30min + 30min = 1 hour to guess a user name.

A scenario where there's no leakage of the existence of the username would make my life way more hard, it would be really discouraging: The math would be ~7200x7200 tries = 51840000 tries . If I manage to get 4 request back from the server that would be 12960000 seconds equals 3600 hours equals 150 days.

So bottom line is a security decision between 1 hour or 150 days for one hacked account in this simple white board scenario. Or to put it the other way round in 150 days in a two step approach I would be guessing 150x24x3600 = 12,960,000 accounts -- mathematically.

This is the reason why no web application tells nowadays anymore whether the user exists or not. Frontends try also to avoid mail addresses as the username if possible as they can be retrieved in the underground for very little money. Pros use anti-automation measures (captchas, deliberate delays, throttling or any other security control) on AuthN functions as this and session management is THE CORE of any web application (​https://www.owasp.org/index.php/Top_10-2017_A2-Broken_Authentication)

A server of mine (Google lists 128k links) has a quarter of its traffic to /wp-login.php or /wp-admin from random IPs. I barely see traffic e.g. trying to find a Typo3 backend or Drupal probes. Can't tell what the WP traffic is about. I do not have wordpress but the mere fact that there are so many probes to an authentication frontend probably means that criminals are actively looking for it in order to do something with it which is not good probably.

As said, I know from my professional experience that there are other places where usernames can be enumerated. But please start with this obvious one and then I would recommend seriously start closing the others. Don't take them as an excuse for this one. There is no real reason for this one.

And please put this on the agenda for internal discussion.

I am reopening.

Thanks!

[earnjam]

Duplicate of #3708.

There are easier ways to scrape and discover usernames than repeatedly submitting the login form.

Even if we changed our position and began considering usernames to be private information, changing the messaging on the login form alone does nothing. It would require restructuring author archive permalinks, breaking changes to the REST API, educating theme developers to not use the username in CSS classes, etc.

That's not to say the work required is the reason we aren't changing it, but just that you're oversimplifying the scope to which usernames are visible to non-authenticated visitors.

But this has all been discussed many times across a bunch of tickets. If you have more to add to the conversation, you can continue the discussion on this ticket without reopening it.

[d0rkpress]

Even if we changed our position and began considering usernames to be private information, changing the messaging on the login form alone does nothing.

??? It removes one possibility -- in security speak one attack vector.

Two reasons for this: There's a percentage of attackers who might not know about the other ways to retrieve usernames. Or, more importantly, the other ones are closed for an attacker because they are measures in place to protect them.

So from the security standpoint this is a lame excuse.

It would require restructuring author archive permalinks, breaking changes to the REST API, educating theme developers to not use the username in CSS classes, etc.

Don't know what you are referring to, but changing the failed login message to what is standard since 15 years doesn't involve a change like this. There's a diff attached to the 12 year old ticket and my guess without looking at the code today is that it is no big change as you indicated.

But this has all been discussed many times across a bunch of tickets. If you have more to add to the conversation, you can continue the discussion on this ticket without reopening it.

I got that and it doesn't make sense to repeat it over and over to me. It seems to me like an excuse that you even don't want to think about it as it requires to leave your comfortable position. Do really you understand the security problem here? Do you acknowledge it? Do you want to think about addressing it somehow in the future?

Insisting on your paradigm doesn't reflect my reality. I do not have good statistics but from the like 10 installations I personally know the operators from, zero want to have the usernames public. And they use every means to keep it that way. This is because they know the math, see my previous post.

So if you are really willing to think about the possibilities closing the other security loopholes I am sure that they will be ways to protect the retrieval of user information per default -- at least for those who want to.

Independent on those loopholes: changing the login message to not leak usernames is a no-brainer.

Please fix that.

​https://www.owasp.org/index.php/Authentication_Cheat_Sheet#Incorrect_Response_Examples
​https://nvd.nist.gov/800-53/Rev4/control/SI-11
​https://cwe.mitre.org/data/definitions/210.html

[knutsp]

Both including a "Limit Login Attempts" functionality in core, demanding more complex passwords and implement two factor auth would be both better and a lot easier to implement than starting huge rewrite to make usernames a secret.

Starting to look at usernames as secrets will lead to users, and security advisors, try to come up with a username as complex as possible, taking focus away from really strong passwords and 2FA.

When user write down or store their credentials, username and password go along. When entered, both are submitted at the same time, so if they leak, both leak.

For 15 years with WordPress I have thaught users to select a simple username, their first named or a nick they are used to, then focus on constructing a unique and complex (strong) password. When logging in, some use a wrong username, but the correct password. I have thaught them to look at the error message to find which is wrong.

Many systems have the username as the only display name. I WordPress, no matter what username you choose, your display name is independent of it.

I can support a long time path to make usernames not part of public slugs, as there is a nice plugin for. This will gain new users only. For existing users, their username may be allowed to change, without affecting the slug ("user_nicename"), which needs to be permanent.

This ticket is starting at the wrong end, except for some discussion, once again. Period.

[d0rkpress]

Starting to look at usernames as secrets will lead to users,

There's more than a subtle difference between treating user names as secret or potentially telling every IP address in the internet by a faulty design to hand out the user name.

And: THIS TICKET IS FIRST ABOUT REMOVING THE ERROR MESSAGE during login.

For 15 years with WordPress I have thaught users to select a simple username .. When logging in, some use a wrong username, but the correct password. I have thaught them to look at the error message to find which is wrong.

Then I guess you have done something wrong during the past 15 years. And you haven't bothered looking at the links I sent nor reading my arguments.

It seems the security mindset of some responding have stopped either in the early twothousands or I am writing in Chinese. So please excuse me if I spending my time on something which makes more sense to me.

Unfortunately is seems I cannot delete my account and unfortunately your IP is in a country which doesn't require this (GDPR does).

[SergeyBiryukov]

#50254 was marked as a duplicate.

[peterwilsoncc]

#52998 was marked as a duplicate.