Apache is the web server which is most frequently used. The Apache Software Foundation (ASF) provides the Apache web server as open source and free. Numerous large platforms, respectively well-known operating systems like Linux, Unix, Windows and Novelles Network as well as many smaller ones are supported.
Apart from the basic functionality as web server the core functionality can be – due to Apache’s modular approach – easily extended with so-called modules. Potential modules are modules for the support of scripting languages like PHP (mod_php5), Perl (mod_perl), Python (mod_python) or Lua (mod_lua) for web server version 2.3 up.

Protective measures for Apache web server

Apart from this, there are other modules in order to increase website security and repel a possible attack. Such modules are the ones for SSL (mod_ssl) or for authentication mod_auth_basic, mod_authnz_ldap or mod_authz_dbm and mod_authz_user), session handling (mod_session and mod_session_crypto) and user administration. A complete overview of all Apache modules can be found on modules.apache.org.

Advantages of Apache / Apache compared to Nginx

Due to these numerous options websites can be easily implemented. The advantages of Apache come forward when providing dynamic content. Another advantage is that Apache and PHP have been used for a long time now and thus show a certain stability. Nginx, however, is faster and more performant as far as static content is concerned.

Apache two-step authentication versus two-factor authentication

Due to the wide distribution of Apache and PHP a lot of hosters use this combination.
A lot of Content Management Systems (CMS) or blog systems are running on a system with Apache and PHP.
Most common examples are certainly WordPress, Joomla, Drupal and Magento. All these systems possess a functionality which is partly similar to the Apache HTTP server: User administration, authentication and SSL/HTTPS. For this reason it is easy to add a two-step authentication. It is important to keep in mind that a two-step authentication and not a two-factor authentication is meant in this context. For a more detailed explanation please see the end of this article or visit our overview.

CMS / Backend and administrator area

Most CMS, respectively blog systems have an administrator area or backend via which particular settings can be made or content can be added to the CMS.
For WordPress one will get to the website URL for the backend by adding /wp-admin/ or
/wp-login.php, for Joomla by adding /administrator/ and for Typo3 /typo3/.
At this point you normally have to authenticate with user name and password. However, the CMS in this area is very vulnerable for DOS-, respectively DDoS-attacks (Distributed-Denial-of-Service) and the infiltration with codes like, for example, Cross-Site-Scripting (XSS) or SQL-Injections. A frequently (mis)used weak point is the XML RPC interface of WordPress. Please also see WordPress Security: Prevent Brute Force and DDoS Attacks . Brute force attacks against Content Management Systems usually happen every single day.

For securing the backend a two-step authentication via Apache can be used. For this you use the authentication system of Apache and connect it in front of the CMS backend. This way you will have two steps. First, you authenticate for Apache and then for CMS. In other words: The first login is on Apache, the second one on CMS.

How to install a two-step authentication with Apache HTTP Server? An option is the use of the module mod_auth_basic and .htpasswd.

Two-Step authentication with Apache

Apache .htpasswd

With Apache’s in-house means you can now prepend a second authentication step so that an attacker must overcome two instead of just one obstacle. Apache´s in-house mean for this is the module mod_auth_basic and the file .htpasswd. Behind it a mechanism for authentication and authorization is hidden. With this mechanism you can easily protect single directories by the use of passwords.

Each directory which is to be secured can possess the file .htpasswd. Thus, the complete website can be secured in small defined units in a finely granular way.
As soon as a file or the content of the directory is requested by a browser or program, Apach will ask for the authentication (if this did not happen before and was stored in an internal Apache session).

Installation of a password protection with htpasswd:

In the file .htaccess which can either be stored in the website´s root directory or analogously to .htpasswd  in any directory you can define which directories are to be protected by user name and password:

# .htaccess for web directory /service
AuthType Basic
# the name of the dialog shown in the browser
AuthName "service"
# where to find the user authentication file: the path must be an absolute one
AuthUserFile /var/www/service/.htpasswd
# which users are accepted
Require

With AuthType you define the authentication type. Normally, only ‚Basic’ is used which stands for HTTP Basic Authentication. The disadvantage of this method is that passwords are tranferred from the browser in an unencrypted form. For the installation of the encrypted transmission of the passwords you have to enter the value ‚Digest‘.

With AuthUserFile you indicate the path to the file in which the authorized users are mentioned. If you, however, use groups of users you also have to indicate a path to a group file via AuthGroupFile. An example can be found below.

It is important that the path to .htpasswd must be absolute. Otherwise, the file cannot be found.

Generation of passwords for .htpasswd

In order to generate a password for the individual users for .htpasswd you use the Unix-command:

htpasswd -cm ./.htpasswd

The flag -c generates a new file. An existing file will be overwritten without any further inquiry. In order to add users and passwords to an already existing file you use the flag -m:

htpasswd -m ./.htpasswd

The content of .htpasswd can look like the following example, if only one user called ‘rachel’ was defined:

rachel:$apr1$ePXh94Ag$BQnmPdhBV7.kxPYJqCIoV.

Use of groups

Another example for groups:

# .htaccess for web directory /service
AuthType Basic
# the name of the dialog shown in the browser
AuthName "management"
# where to find the user authentication file
AuthUserFile /var/www/management/administrator/.htpasswd
# where to find a group file
AuthGroupFile /var/www/management/administrator/.htgroups
# which users are allowed
Require user john jane rachel
# to which group the user must belong to
Require group specialist

The content of the group file might look like in the following example:

# users for group
specialist:john jane rachel dan bob vanessa

The users following this group name must be indicated in the .htpasswd file.

The access protection takes place for the directory indicated in .htaccess and its subdirectories. There are many options to organize the access in a more fine granular way. In .htaccess the access to certain file types can be limited:

# .htaccess for web directory /service
AuthType Basic
AuthName "service"
AuthUserFile /var/www/service/.htpasswd
Require user rachel jane vanessa
Require group specialist

Besides, the authentication can also be limited to single access types like POST or GET. (Available for Apache 2.0.20 and up. Allowed are: POST, GET, PUT, DELETE, CONNECT, OPTIONS)

# .htaccess for web directory /service
AuthType Basic
AuthName "service"
AuthUserFile /var/www/service/.htpasswd
Require user rachel jane vanessa

In the example only the access via GET was limited and was asked for an authentication. Access via POST is still allowed.

It is also possible to limit the access for certain website areas via IP addresses. This, however, is only possible for 2.2.x and up:

# .htaccess for web directory /service
AuthType Basic
AuthName "service"
AuthUserFile /var/www/service/.htpasswd
Require user rachel jane vanessa
Order allow,deny
Deny from .aol.com
Allow from 10.0
satisfy any

With these two mechanisms separate admin areas like, for example,
www.mysite.org/administrator/  can be provided with a second authentication. If a user successfully logs in, he will be redirected (in the example www.mysite.org/administrator/ the user would be redirected to the Joomla login). Thus, it is clear why this kind of authentication is called a two-step authentication.

In addition to the two-step authentication there is also the two-factor authentication.
Bruce Schneier even calls it to some extent a two-channel-authentication.
Normally, the two-factor authentication is based on the principle that a user KNOWS something and HAS something.
An example is the smartcard or the credit card. The user physically possesses the card and knows the PIN in order to authenticate. In contrast to this the two-step authentication only asks the user for the knowledge factor even though „more“ knowlege is required than for a simple login.

Instead of installing a two-step authentication on the backend areas of various Content Mangement Systems with Apache and htpasswd, the installation of a two-factor authentication would be more beneficial. It can, for example, be easily carried out with the SecSign ID plugins for WordPress, Joomla or Drupal.

The authentication is again based on the principle of the factor „possession“ (something can be produced) and the factor „knowlege”. In this case this would be your smartphone (possession) and the PIN for the SecSign ID on your smartphone (knowledge).
Besides, one can see that we have in this case a real two-channel authentication as explained by Bruce Schneier as the entry of the SecSign ID in the backend area is made on another channel than the one for the real authentication on the smartphone. It somethimes even happens via another network (if, for example, the smartphone is in the local network and not in WLAN).

Also special about this login with SecSign ID is that you have to store passwords neither in CMS nor in Apache. Thus, the Content Management System is protected against brute force attacks and attacks with the goal to get passwords or password hashes.

Just try it out and see for yourself: www.secsign.com/try-it/

If you notice that some programming languages or CMS’s are not yet supported by us, please write to info@secsign.com. We are always looking forward to your feedback.