Remove 'admin' as default username in install

[chrisrudzki]

The installation process populates the username field with 'admin' by default.

Many/most users probably leave it as-is, making them more vulnerable to brute force attacks that look out for "admin" usernames.

Seems a pretty easy improvement to specify no default username, and force the user to choose one themselves.

[mark-k]

I don't think this is major in any way. User names in wordpress are public knowledge (can be retrieved from author page url) so while I agree that there is no reason to have a default user name, it doesn't add much security (I guess that is the point of this ticket).

[chrisrudzki]

Replying to mark-k:

I don't think this is major in any way. User names in wordpress are public knowledge (can be retrieved from author page url) so while I agree that there is no reason to have a default user name, it doesn't add much security (I guess that is the point of this ticket).

It's low hanging fruit. Many people are suggesting that users change their usernames away from "admin" anyway (e.g., ​http://ma.tt/2013/04/passwords-and-brute-force/), so let's encourage users to not use it in the first place.

I don't know how "much" security it adds. But my impression is that the current crop of bots are trying sites with "admin" usernames.

Regardless of whether the username is discoverable, this is a pretty simple step that'll either add some protection or, in the worst case given more sophisticated bots, no extra protection. It's also worth considering that many users will probably keep their usernames around for a while, so it's worth addressing this sooner than later.

[mark-k]

It is not major because it is a feature request and not a bug as you haven't demonstrated that there is something which doesn't work. In my experience users don't select admin as a user name even if there is some code path in which it is a default. ("admin" is natural administrator user name only for english speakers).

Regardless of whether the username is discoverable, this is a pretty simple step that'll either add some protection or, in the worst case given more sophisticated bots, no extra protection. It's also worth considering that many users will probably keep their usernames around for a while, so it's worth addressing this sooner than later.

3.6 is in beta, so IMO later is the only option when you want to touch something critical like install procedure, no matter how trivial a change might look.

[Viper007Bond]

This is an enhancement and those are rarely major. Severity is not a big deal though. :)

Anyway, I'm behind leaving the username field blank. +1

[ziegenberg]

+1

[SergeyBiryukov]

Related: #14644

[norcross]

+1

[jtallant]

Replying to mark-k:

I don't think this is major in any way. User names in wordpress are public knowledge (can be retrieved from author page url) so while I agree that there is no reason to have a default user name, it doesn't add much security (I guess that is the point of this ticket).

Defaulting the user name to 'admin' is definitely a security issue. That user name is being targeted in brute force attacks. If it wasn't being targeted, it wouldn't be considered a vulnerability. The fact that other user names are discoverable doesn't make it less of a vulnerability, it simply points out yet another vulnerability. Why are user names discoverable? That's a little silly. Why do users need user names and an email address? Why does WordPress tell you when you have guessed the right user name but got the password wrong and vice versa?

Make the user name the email address. Do away with "user name" and add an (optional) author name. The author name can be what is displayed publicly, the email address should become the login. You could use the first/last name as the author name if they provide one and not even have an author name (I know these options exist in WP but I'm talking about installation fields).

Instead of yourblog.com/author/username it should work like this...

If author name exists

yourblog.com/author/authorname (not the same as your admin log in)

If no author name exists but a first/last name exists

yourblog.com/author/first-last

If no author name and no first/last name.

yourblog.com/author/1
1 being the unique id of the user (auto-incrementing id from DB)

Do this and do away with anything else that makes the user login detectable.

Assuming WP starts defaulting user names to email addresses, some one will certainly point out that your email address is probably displayed publicly on your site somewhere, and if it is displayed publicly, it can be scraped for and used in brute force attacks as well. That is true but I suspect this occurs much less often and is more difficult to do than brute forcing for admin successfully.

I think all the changes above should be considered important but I still believe enforcing stronger passwords is more important.

[SergeyBiryukov]

Replying to jtallant:

Why does WordPress tell you when you have guessed the right user name but got the password wrong and vice versa?

Related: #3708, #5301, #12129.

Instead of yourblog.com/author/username it should work like this...

Related: #20235

I think all the changes above should be considered important but I still believe enforcing stronger passwords is more important.

Related: #21737

[ryansatterfield]

This majorly impacts people who use the username Admin. Unfortunately, too many people use the default username. Maybe In 3.5.2 when the person logs in, you could check to see if the username is admin and if it is, then let them reset it? I'll work on a patch later, if someone doesn't beat me to it.

[chrisrudzki]

Replying to ryansatterfield:

This majorly impacts people who use the username Admin. Unfortunately, too many people use the default username. Maybe In 3.5.2 when the person logs in, you could check to see if the username is admin and if it is, then let them reset it? I'll work on a patch later, if someone doesn't beat me to it.

Not sure how it "majorly impacts" people already using the 'admin' username. It's a suggestion to leave the username field blank during installation, rather than populating it with 'admin'.

Checking if someone's already using the 'admin' username, and allowing them to change it, is outside the scope of this ticket. Changing usernames is specifically addressed in #14644

[ryansatterfield]

Replying to chrisrudzki:
I'd like to address something you removed in an editsince a lot of people believe this isn't that important. "Not sure how it "majorly impacts" people already using the 'admin' username." The way this works is that the automated scripts look for the name admin and then starts brute-forcing the site. For more information on how this works read my companies article ​http://planetzuda.com/news/2013/04/14/wordpress-security-tips/.

Replying to ryansatterfield:

This majorly impacts people who use the username Admin. Unfortunately, too many people use the default username. Maybe In 3.5.2 when the person logs in, you could check to see if the username is admin and if it is, then let them reset it? I'll work on a patch later, if someone doesn't beat me to it.

I think checking if someone's already using the 'admin' username, and allowing them to change it, is outside the scope of this ticket. Changing usernames is specifically addressed in #14644

[chrisrudzki]

Replying to ryansatterfield:

I'd like to address something you removed in an editsince a lot of people believe this isn't that important. "Not sure how it "majorly impacts" people already using the 'admin' username." The way this works is that the automated scripts look for the name admin and then starts brute-forcing the site.

I agree. That's why I filed this ticket. :)

[kovshenin]

+1. Discoverable user names is a different problem and usually not an issue during automated attacks. I read this ticket as "stop suggesting admin as a username" and it makes perfect sense.

[mor10]

Thanks for adding this. It is an important update because new users are not made aware the "admin" username has inherent problems. While it won't prevent hacking per se it is a simple way to make it a lot harder to set up botnet attacks. WordPress should be set up to help the new user have a secure site and this will go a long way to ensure that happens.

[rdall]

+1

[lumpysimon]

+1 (for the original scope/patch)

[chipbennett]

Seems a pretty easy improvement to specify no default username, and force the user to choose one themselves.

+1

[norcross]

I honestly can't think of a web service / site I've signed up for in the last few years that created a username for me.

If we are telling people not to use it (which Matt did in a recent post) then we certainly shouldn't auto fill it.

[bradparbs]

+1 to removing it. I don't think having someone add a username is too much of a problem.

[MAzZY]

Seems a pretty easy improvement to specify no default username, and force the user to choose one themselves.

I agree with this.

mark-k is absolutely right

[beaulebens]

I'm curious what the discussion here is really about. Is there any actual, real reason why this *wouldn't* be implemented?

[ocean90]

#24550 was marked as a duplicate.

[lovingboth]

Ah, I missed this one when searching to see if it had been done earlier - thank you ocean90. I am surprised it is so recent.

I cannot believe that any of the developers would suggest that a friend new to WordPress use 'admin', but this has been what has been happening on every new site's setup page for the past three years (before then, it was inflicted on users because they didn't get to choose the initial user name!) The result is that it's the one that the vast majority of attacks go for, on the extremely likely to be correct assumption that it's an administration account on a very large number of sites.

As it is, WordPress suggests you pick an obvious username for the first administration account, has no password strength enforcement for it, and then lets attackers have as many attempts at hacking it as they like, as fast as the webserver will let them. Is that really thought to be a good idea?

At least this will force attackers to find usernames. This patch should be in 3.6, and not have to wait for 3.7.

[webvitaly]

+1 for removing 'admin' user by default.

It is easy to make, but it could solve so many security problems.
More than 90% brute-force attacks targeted to crack 'admin' username.

[lovingboth]

Today's thought is that a patch to stop people using 'admin' as a username for an account would be a 3.7 feature.

But when Matt has said in his ma.tt blog that people should stop using it, why delay an ultra simple change that will end actively suggesting it in every new install?

[wonderboymusic]

these are all marked 3.7-early

[ryan]

In 24998:

Remove 'admin' as default username in install.

Props chrisrudzki
fixes #24078

[nacin]

Beyond [24998], it would be nice if install.php reacted a bit better when there was an error. "ERROR: you must provide a valid username." is okay, but certainly not ideal. Needs better poka-yoke! New ticket, anyone?

[tivnet]

What about line 193?

192	                $weblog_title = isset( $_POST['weblog_title'] ) ? trim( wp_unslash( $_POST['weblog_title'] ) ) : '';
193	                $user_name = isset($_POST['user_name']) ? trim( wp_unslash( $_POST['user_name'] ) ) : 'admin';
194	                $admin_password = isset($_POST['admin_password']) ? wp_unslash( $_POST['admin_password'] ) : '';

[DrewAPicture]

Shouldn't we also remove 'admin' in the second ternary, allowing the error to get tossed when $user_name is empty? 24078.diff​

Replying to nacin:

Beyond [24998], it would be nice if install.php reacted a bit better when there was an error. "ERROR: you must provide a valid username." is okay, but certainly not ideal. Needs better poka-yoke! New ticket, anyone?

I cringed at install.php for a while last night. I'll make a ticket.

[dd32]

Nacins thought were spun off into #24982

Agreed with removing the default fallback here too.

[SergeyBiryukov]

Replying to DrewAPicture:

Shouldn't we also remove 'admin' in the second ternary, allowing the error to get tossed when $user_name is empty? 24078.diff​

That fallback actually appears to be unreachable, since $_POST['user_name'] is always set. However, removing it for consistency makes sense.

[SergeyBiryukov]

In 25115:

Remove 'admin' as a fallback for username in install. props tivnet, DrewAPicture. fixes #24078.

[johnbillion]

Side-effect: #27093

[nacin]

In 27822:

Install: Allow an installation to go through with a custom user table with the username 'admin'.

This could be better, but this solves the regression caused by [25115].

fixes #27093, see #24078.