WP 4.4.2 still allows visibility of usernames (admins, post authors) – CONTINUED

Hi there,

I’ll be your designated antsy moderator for this thread ??

The username hiding concept is very played out, for most services (think facebook, youtube, gmail, twitter and so forth) your username is your email address, you willingly distribute what you are pointing out to be a paramount part of any sites security mechanism multiple times on a daily basis, and as such the whole username debate is quite moot.

If you worry about security, install 2-factor authentication and use strong passwords, a username plays little to no role in this puzzle in this day and age.

Now, as I am antsy I will just end this thread as well, as there are countless threads like this, they all go in circles and do not offer anything of value at this point.

Should you have an actual solution to your problem, I welcome you to make a thread with it, but just the discussion of “usernames are secret” is played out and over with.

You know what? Nope. Let’s have this one out.

Again, my username is otto. Now, let’s assume that keeping that secret is a good thing. Let’s assume you’re right.

If I was to keep that public, but change the system to require TWO passwords, would that be the same thing? Two secrets in both cases right? Or should I now have three secrets? Is that better than two? Why not four? Where do we reach the secret word limit of security here?

Even if we had four whole secrets, could we perhaps simplify those? They’re just text. Maybe we could concatenate those together into a long single secret. We could call it a “password”, perhaps. One long password to contain all our secrets. Much easier. Then, that means I can keep using “otto” without any worries.

There’s three types of security identifiers. Something you know (password), something you are (thumbprint, perhaps), something you have (key, 2 factor device, etc). Using the same one of something-you-know twice isn’t any better than using it once with more information included in it.

Hiding usernames is equivalent to making a longer password, except notably worse because we train people to keep their passwords a secret, but we don’t train them to keep usernames a secret. Because keeping two secrets makes no sense. Not really.

If you actually want better security, use two factor. Add in that something-you-have. And use a better password. Then knowing your username is meaningless. It’s an identifier. Nothing more.

Quite. But why give hackers the identity mechanism in the first place?
If you have two locked locks on a door, do you leave one key under the mat and take the other with you? No because that eliminates 50% of the time it takes to pick both locks.

If an attacker doesn’t have the login name you can use WordFence to Block (X) attempts to login from a certain IP. With a high amount of assurance that it’s not you trying random user names…

Attacker visits website.
attacker discovers blog author names
attacker attempts login in by author names over and over and over
attacker only needs to guess the password.

The User Name may be currently a “public key” by Default for WordPress but you can choose as a user to keep that key Private by setting a “Display Name” on your user Profile.
A Display Name, which cannot be used for login.

You can now treat your “Public Key” – your login name as a “Private key”

You may “login everywhere” with an e-mail address, and thats great for Facebook and Google. Because they have SecOps teams to monitor security and attacks.

You are a mom and pop shop setting up your own WordPress site, you probably don’t have a SecOps team or money for a SecOps Team. Maybe you pay for WordFence or iThemes or DUO. But do you really NEED to???

2FA aside. 2FA is not part of WP Core.
Telling an End User, new to the platform to go use this other third party service; destroys Trust in WordPress Brand Identity. Thats like saying, Oh, we’re not concerned with Security at WordPress. Go ask those guys over there with the printed security badges.

attacker attempts login in by author names over and over and over

Were you aware that there are plugins that can limit the number of attempted logins in any given time period? Some host 1-click WP installs now add such a plugin by default.

I think you’re missing the fundamental point here.

This is the standard behavior. Usernames are not private information. They never have been. We don’t make any attempt to secure them. Nobody makes any attempt to secure account identifiers, because that makes no actual sense.

The security of your account is, and always has been, entirely in the password.

Google and Facebook use your email address as the account identifier. Your email address is well known, to anybody whom you ever sent email to. Are these services insecure because people know your email address?

Twitter lets you login with your email, your Twitter name, or even your phone number in some cases. Their account identifier is so “insecure” that it’s easy to guess for practically anybody.

WordPress isn’t alone on this one. Drupal agrees.

Basically, the idea of “keeping your username secret” is flawed from the start. The underlying thinking here is that “knowing 2 things is harder than knowing 1 thing”, but that’s not the case at all. Knowing 1 thing, your password, is *arbitrarily* difficult. If you think you need your username to be secret, then your password is not difficult enough.

This isn’t like lockpicking. Knowing 2 separate secrets is not really any different from knowing 1 long secret. If I know “username” and “password”, then I know the combined secret of “username-password”. Making “password” harder makes the whole thing harder.

My password is incredibly difficult. So difficult that I don’t even know what it is. I use services like LastPass. A lot of people like 1Password. Your password should be hard enough to not be susceptible to brute-force attacks in the first place. Whether an attacker knows your username or not is irrelevant if they can’t get your password. Which is, in fact, the whole point of having a password.

I agree with you wholeheartedly Otto. I also recognize the argument that “Usernames are a security feature” is played out with the majority leaning toward the “meh”.

However “They never have been” doesn’t mean “they shouldn’t be.”

I also know there are plugins to disable login attempts etc. I employ them on several sites and I personally have built a fair amount of trust in them. But I am not every WordPress User Persona. I and not “New user to the platform looking for something secure to setup my family store blog” or web store.

My concern is for the Users who don’t employ LastPass or 1Password tools for long passwords. New Users getting to know and learn WordPress. There are a ton of plugins on the market and that can be overwhelming to New users of the WP Platform. Telling them to go forth and find something for their needs is not a good default practice, they might as well just go forth and choose another platform. But maybe they want something easy and something trustworthy because they are trying to build up business.

The thought process should be, “why make it any easier for the attackers?”
Not “They can guess your Username from _____ sites anyway so why go to the trouble of having WordPress Provided Theme/Plugin obfuscate it?”

Simply this: Make it a choice for the user to obfuscate the login name by default when they set a Display Name. Not vice-versa.
They don’t have to set a display name, it defaults to the username anyway. But if they have any concern of sharing their login credential then they can use the Display Name for Public Display.

Teach Theme Devs and Plugin Dev’s not to include user ID’s in URL Strings, when the core offers the option of including the “Display Name” in it’s stead.
https://core.trac.www.ads-software.com/browser/tags/4.5.2/src/wp-includes/author-template.php#L296

Also, weather we recognize User Name as a key or not, it is part of the login workflow. If you don’t give it away it DOES make it harder to guess the entry, as you stated it makes the pass-code longer. Weather it is expected to by development or not. Taking the stance of Teaching users/themeDevs/pluginDevs to keep the login name private adds a layer. It’s there as an option.

The argument that “the other industry leaders do it” is not a good evaluation. If other industry leaders are jumping off a cliff, should WordPress? Other Industry leaders have security Teams, End Users of WordPress may not. They rely on WordPress to be trustworthy and not share login credentials unexpectedly.

The argument that WordPress users need to turn to another service/tool for 2FA “something you have” component. Is also not a great one, though relevant, it still relies on End Users picking/building trust in another unknown tool. Expecting your end users to go away from Core Services and choose some other thing to maintain is not a good policy for any platform. That harks of old Operating System perspective to Security. People had to turn to myriad of other Firewalls, breaking trust in the Core Product ability to be secure.

Perhaps if WP were to Make 2FA – “something you have” – an option as part of WP Core Service and then this debate might end. The user has the option to enable it; or not: and they don’t have to go elsewhere for the service.

Also, most OS’s now, you can choose to show as List of registered users or a Name and Password form (like WP Login displays). The point of this is, someone sitting down to try logging in, would need be savvy with the OS tech to search for the available registered user names just to begin cracking the password field. If the computer is not encrypted, they could find the names in the Users directory.
So why leave the username field hidden anyway if you are not going to encrypt it? because it makes it harder to guess at the entry point.

What can we do to make it harder for attackers? obfuscate the login name.

@twintails said:

What can we do to make it harder for attackers? Obfuscate the login name.

You’re invited – not that anyone needs a invite – to jump in and add 2FA (as well as other security features) as options to WordPress core: https://make.www.ads-software.com/core/

Try the Clef plugin. You can set it so the regular id/password login is disabled on login is only via the phone app which uses public/private key access.

@twintails Yeah, we’re really leaning kind of the other way around here. You may have noticed that the latest versions of WordPress also let you login using your email address, not just your username. It simply is not a security issue to have your username known by an attacker. It is a security issue to let your password be weak.

To that effect, WordPress now defaults to using very strong passwords, and only lets you choose weak ones by checking a box saying that you acknowledge that it is a bad password. These are real changes that make measurable differences.

The problem with brute force attacks is not so much them getting in (use a strong password, and they won’t). The problem is simply that sites become overloaded. A plugin can’t really fix that issue, because the overload is simply a matter of too many requests. For that problem, you have to look lower in the stack than PHP. You have to configure the server properly, or have a host do it for you. Trying to block excessive http requests is not something you try to fix in the PHP script. Doesn’t work.