WordPress.org

Make WordPress Core

Opened 15 months ago

Closed 11 months ago

Last modified 4 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 15 months ago.
24078.diff (859 bytes) - added by DrewAPicture 11 months ago.

Download all attachments as: .zip

Change History (45)

chrisrudzki15 months ago

comment:1 kovshenin15 months ago

  • Cc kovshenin added

comment:2 follow-ups: mark-k15 months 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: chrisrudzki15 months 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-k15 months 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 Viper007Bond15 months ago

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

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

Last edited 15 months ago by Viper007Bond (previous) (diff)

comment:8 SergeyBiryukov15 months ago

  • Version changed from trunk to 3.5

comment:10 sc0ttkclark15 months ago

  • Cc lol@… added

comment:11 in reply to: ↑ 2 ; follow-up: jtallant15 months 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 toscho15 months ago

  • Cc info@… added

comment:13 in reply to: ↑ 11 SergeyBiryukov15 months 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: ryansatterfield15 months 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: chrisrudzki15 months 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.

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

Version 0, edited 15 months ago by chrisrudzki (next)

comment:16 in reply to: ↑ 15 ; follow-up: ryansatterfield15 months 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 chrisrudzki15 months 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 kovshenin15 months 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 Hanni15 months ago

  • Cc h@… added

comment:20 in reply to: ↑ 3 mor1015 months 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 lumpysimon15 months ago

+1 (for the original scope/patch)

comment:23 chipbennett15 months ago

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

+1

comment:24 norcross15 months 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 sunnyratilal15 months ago

  • Cc ratilal.sunny@… added

comment:26 bradparbs15 months 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 MAzZY15 months 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 beaulebens14 months 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 SergeyBiryukov14 months ago

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

comment:30 ocean9013 months ago

#24550 was marked as a duplicate.

comment:31 lovingboth13 months 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 webvitaly13 months 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 lovingboth13 months 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 wonderboymusic11 months ago

  • Milestone changed from Future Release to 3.7

these are all marked 3.7-early

comment:35 ryan11 months 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: nacin11 months 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 tivnet11 months 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'] ) : '';

DrewAPicture11 months ago

comment:38 in reply to: ↑ 36 ; follow-up: DrewAPicture11 months 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 dd3211 months ago

Nacins thought were spun off into #24982

Agreed with removing the default fallback here too.

comment:40 in reply to: ↑ 38 SergeyBiryukov11 months 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 SergeyBiryukov11 months 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:42 johnbillion5 months ago

Side-effect: #27093

comment:43 nacin4 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.