The format of a rule is:

<'allow' | 'deny'> <username> [from] <source>

The from keyword is optional. Here are some examples:

Usually we will have several rules. Let's say we wish to have the two rules that follow:

allow Marc from 45.34.23.12
allow Melanie from all

We have to put them in config.inc.php (in the related server-specific section) as follows:

$cfg['Servers'][$i]['AllowDeny']['rules'] = array('allow Marc from 45.34.23.12', 'allow Melanie from all');

When defining a single rule or multiple rules, a PHP array is used. We must follow its syntax, enclosing each complete rule within single quotes and separating each rule from the next with a comma. Thus, if we have only one rule, we must still use an array to specify it like this:

$cfg['Servers'][$i]['AllowDeny']['rules'] = array('allow Marc from 45.34.23.12');

The next parameter explains the order in which rules are interpreted.

By default, this parameter is empty:

$cfg['Servers'][$i]['AllowDeny']['order'] = '';

This means that no IP-based verification is made.

Suppose we want to allow access by default, denying access only to some username/IP pairs. We should use:

$cfg['Servers'][$i]['AllowDeny']['order'] = 'deny,allow';

In this case, all deny rules will be applied first, followed by allow rules. If a case is not mentioned in the rules, access is granted. Being more restrictive, we'd want to deny by default. We can use:

$cfg['Servers'][$i]['AllowDeny']['order'] = 'allow,deny';

In this case, all allow rules are applied first, followed by deny rules. If a case is not mentioned in the rules, access is denied. The third (and most restrictive) way of specifying the order of rules is:

$cfg['Servers'][$i]['AllowDeny']['order'] = 'explicit';

Now, deny rules are applied before allow rules. But for them to be accepted, a username/IP address must be listed in the allow rules, and not in the deny rules.

As the root user is present in almost all MySQL installations, it's often the target of attacks. A parameter permits us to easily block all phpMyAdmin logins of the MySQL's root account, by using the following:

$cfg['Servers'][$i]['AllowRoot'] = FALSE;

Some system administrators prefer to disable the root account at the MySQL server level, creating another less obvious account that possesses the same privileges. This has the advantage of blocking root access from all sources, and not just from phpMyAdmin.

The contrib/swekey.sample.conf sample file should be used as a starting point to configure this feature. This file contains sample configuration commands and comments from the vendor. The principle is simple—each Swekey device contains a unique ID, and this ID must be associated with a MySQL username in the Swekey configuration file. These lines are part of the sample file:

0000000000000000000000000000763A:root
000000000000000000000000000089E4:steve
0000000000000000000000000000231E:scott

This means that the person responsible for the phpMyAdmin configuration tracks which Swekey is given to each user and puts this information in the file. The vendor does not need to be informed about this association. They only keep track of which Swekeys are sold and which are deactivated. Hence, a Swekey can be passed from one user to another, provided that the configuration is updated accordingly.

Other security-related directives are in the sample file, and it's recommended to refrain from changing them—SERVER_CHECK, SERVER_RNDTOKEN, and SERVER_STATUS in particular. This is because these directives access servers via https, which is a guarantee of a secure channel between our web server and the vendor's.

Once modified, this file should be copied over to a directory outside of the web server's document root (suggested place is /etc/swekey-pma.conf). Then, a configuration parameter in config.inc.php must be set as well:

$cfg['Servers'][$i]['auth_swekey_config'] = '/etc/swekey-pma.conf';

Let's see what happens now when phpMyAdmin is started and no Swekey is connected to your workstation:

We notice three changes:

It's normal that the username field is deactivated, as usernames are now taken from the Swekey configuration file. The icon can be clicked to reach the vendor's website. There is a testing mechanism on this site, to verify if a Swekey is connected. Drivers can also be downloaded in case the automatic installation did not work.

Now if you connect your Swekey, assuming that user marc has been defined and associated to this device, a reassuring panel is displayed:

It would not make sense to rely on the protection offered by this device, if our users have access to a webspace on which they can install their own copy of phpMyAdmin. Obviously, phpMyAdmin has to be configured accordingly to make use of the Swekey. Hence, a user-installed copy of phpMyAdmin would circumvent the protection. This means that a host provider should permit access to his MySQL server only from a web server on which he or she installed a controlled copy of phpMyAdmin, and on which other users cannot install their own copy.

If phpMyAdmin detects the presence of the apache_note() function, it automatically creates the following notes during the login process:

The possible status messages are:

Up to now, the notes are only present inside the Apache system. Normally we want to see them, therefore we will modify Apache's logging configuration to achieve this goal. The exact recipe for this depends on the configuration file name chosen by the distributor of Apache, but we'll use the most common one: httpd.conf.

This file usually contains a LogFormat directive that controls which information goes into one of Apache's log file. phpMyAdmin's documentation suggests this modified directive:

LogFormat "%h %l %u %t \"%r\" %>s %b \
\"%{Referer}i\" \"%{User-Agent}i\" %{userID}n %{userStatus}n" \ pma_combined

We recognize the userID and userStatus notes coming from phpMyAdmin, coated with Apache's special characters. Hence we can apply this newly-configured pma_combined format to Apache's access log with:

CustomLog "logs/access_log" pma_combined

After restarting Apache, all login attempts will be logged and can be analyzed for statistical or security purposes.