The Drupal account created during installation (user #1) is a special account. Primarily, it bypasses all access callbacks - meaning it has all permissions by default. Failing to secure this account could result in potential security risks. You can think about the user/1 account as you would with root on Linux systems.

There are several options to secure this account:

Use other accounts for normal administration

First, you should create (or use an existing role) for the administrative accounts on the site. Grant only the permissions required to do admin work to this role. Grant this role to just the people who truly need it.

Ensure repeated login attempts are rejected

Protection against brute-force attacks has been added to Drupal 7 core. For a configurable interface on Drupal 7, use the Flood Control module.

Do not name first account 'admin'

Do not use an obvious name like 'admin' or 'administrator' which are too easy to guess.

Disable it entirely

With the advent of tools like Drush to run the update hooks and the creation of the administer software updates permission, logging in as UID=1 is no longer required.

Disabling login as UID 1 or as admin username

With Drush, you can disable this account by running the following at a command prompt:

drush user-block 1

Using Drush >= 9
drush user-block admin (replace admin with the name of your admin account if you renamed it).

If you do not have access to Drush, you can run a SQL query instead. The table you must target is different, between Drupal 7 or older:

UPDATE users SET status = 0 WHERE uid = 1

and Drupal 8:

UPDATE users_field_data SET status = 0 WHERE uid = 1

Re-enabling UID=1 or as admin username

The following Drush command or SQL statement re-enables the account:

drush user-unblock 1

Using Drush >= 9
drush user-unblock admin (replace admin with the name of your admin account if you renamed it).

By default, unblocking a user will send them an Account activation email (configurable in /admin/config/people/accounts - Drupal 8)

UPDATE users SET status = 1 WHERE uid = 1 (Drupal 7)
UPDATE users_field_data SET status = 1 WHERE uid = 1 (Drupal 8)

Generate a long, randomly generated password for this account

Drupal's user_password() function can be used to generate a random alphanumeric password. You could set the admin account to a long, hard to guess password to make it less likely the account can be taken over. To generate a long random password using Drupal, run the following Drush command:

drush php-eval 'print user_password(24);'

Note that there are other generators out there that will likely create more secure passwords, including symbols and other characters. Consider using those if you have access to them.

Use the Paranoia module to disable editing this account

The Paranoia module for Drupal 7 will disable editing of the UID=1 account, preventing someone with access to your site from re-enabling it and then using it to log in and escalate privileges.

Take care to evaluate all of the features of Paranoia: it performs several other security and good-practice functions, such as disabling the PHP input filter.

Use Alert to Administrator modules to remind admins they have logged in as an admin

Alert to Administrator displays a configurable alert message above most forms on the site, reminding users they are logged in as an administrator.

Limit access by IP address to only trusted users

The Restrict Login or Role Access by IP Address module can prevent access from untrusted locations.

Legacy considerations for Drupal 6

Drupal 6 is no longer supported, but here is some legacy advice for such sites.

Brute-force attacks

Drupal 6 does not protect against brute-force login attempts by default. Instead, the Login Security module can be installed on Drupal 6 to add this functionality.

Disabling UID=1 entirely

Note that, in Drupal 6 if you didn't use drush, this account was required for running update.php and some other vital user functions. You might therefore need to re-enable it temporarily for specific administrative tasks. Ensure you disable it again afterwards.

Comments

elgandoz’s picture

In Drush 9 and 10, you can no longer disable user 1 (or any other) with the UID, but you're forced to use the username, which in my opinion is not secure, especially if you have several environment with lots of devs.
You can still use the SQL, but it is a bummer:
drush sqlq "UPDATE users_field_data SET status = 0 WHERE uid = 1"