WordPress.org

Make WordPress Core

Opened 2 years ago

Closed 2 years ago

Last modified 17 months ago

#24078 closed enhancement (fixed)

Remove 'admin' as default username in install

Reported by: chrisrudzki Owned by: ryan
Milestone: 3.7 Priority: normal
Severity: normal Version: 3.5
Component: Upgrade/Install Keywords: has-patch commit
Focuses: Cc:

Description

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.

Attachments (2)

24078.patch (751 bytes) - added by chrisrudzki 2 years ago.
24078.diff (859 bytes) - added by DrewAPicture 2 years ago.

Download all attachments as: .zip

Change History (45)

@chrisrudzki2 years ago

comment:1 @kovshenin2 years ago

  • Cc kovshenin added

comment:2 follow-ups: @mark-k2 years ago

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).

comment:3 in reply to: ↑ 2 ; follow-up: @chrisrudzki2 years ago

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.

comment:4 @mark-k2 years ago

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.

comment:5 @Viper007Bond2 years ago

  • Severity changed from major to normal
  • Type changed from defect (bug) to enhancement

Patch looks fine to me, although I didn't test it.

Version 0, edited 2 years ago by Viper007Bond (next)

comment:8 @SergeyBiryukov2 years ago

  • Version changed from trunk to 3.5

comment:10 @sc0ttkclark2 years ago

  • Cc lol@… added

comment:11 in reply to: ↑ 2 ; follow-up: @jtallant2 years ago

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.

comment:12 @toscho2 years ago

  • Cc info@… added

comment:13 in reply to: ↑ 11 @SergeyBiryukov2 years ago

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

comment:14 follow-up: @ryansatterfield2 years ago

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.

comment:15 in reply to: ↑ 14 ; follow-up: @chrisrudzki2 years ago

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

Last edited 2 years ago by chrisrudzki (previous) (diff)

comment:16 in reply to: ↑ 15 ; follow-up: @ryansatterfield2 years ago

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

comment:17 in reply to: ↑ 16 @chrisrudzki2 years ago

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. :)

comment:18 @kovshenin2 years ago

+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.

comment:19 @Hanni2 years ago

  • Cc h@… added

comment:20 in reply to: ↑ 3 @mor102 years ago

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.

comment:22 @lumpysimon2 years ago

+1 (for the original scope/patch)

comment:23 @chipbennett2 years ago

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

+1

comment:24 @norcross2 years ago

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.

comment:25 @sunnyratilal2 years ago

  • Cc ratilal.sunny@… added

comment:26 @bradparbs2 years ago

  • Cc brad@… added

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

comment:27 @MAzZY2 years ago

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

comment:28 @beaulebens2 years ago

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

comment:29 @SergeyBiryukov2 years ago

  • Keywords commit 3.7-early added
  • Milestone changed from Awaiting Review to Future Release

comment:30 @ocean902 years ago

#24550 was marked as a duplicate.

comment:31 @lovingboth2 years ago

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.

comment:32 @webvitaly2 years ago

+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.

comment:33 @lovingboth2 years ago

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?

comment:34 @wonderboymusic2 years ago

  • Milestone changed from Future Release to 3.7

these are all marked 3.7-early

comment:35 @ryan2 years ago

  • Owner set to ryan
  • Resolution set to fixed
  • Status changed from new to closed

In 24998:

Remove 'admin' as default username in install.

Props chrisrudzki
fixes #24078

comment:36 follow-up: @nacin2 years ago

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?

comment:37 @tivnet2 years ago

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'] ) : '';

@DrewAPicture2 years ago

comment:38 in reply to: ↑ 36 ; follow-up: @DrewAPicture2 years ago

  • Keywords 3.7-early removed
  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

comment:39 @dd322 years ago

Nacins thought were spun off into #24982

Agreed with removing the default fallback here too.

comment:40 in reply to: ↑ 38 @SergeyBiryukov2 years ago

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.

comment:41 @SergeyBiryukov2 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 25115:

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

comment:43 @nacin17 months ago

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.

Note: See TracTickets for help on using tickets.