Via cPanel, shared hosting providers tend to offer password protection, a watered-down version of mod_auth, Apache's ‘basic' authentication module that allows access to a directory and its sub-tree only to those with credentials. “Only to those with credentials”? Well, OK, only to the few with credentials, plus the many who've seen some Youtube video on how to hack the thing!
These days, the best reason to understand basic is as a knowledge primer for then setting up one of its more complicated and super-safe cousins. vpsBible generally recommends mod_auth_digest.
- To house private files to which you need access from anywhere
- By developers fine-tuning a new blog theme
- For a client zone on a commercial site
- As an extra layer of protection for, say, wp-login or phpMyAdmin
The procedure is to choose a directory, granting access to specified users. These privileged directory users are separate from, and should not be confused with, your server or WordPress users, the control being governed by Apache rather than by Linux or your WordPress database. That's a good thing, adding an independent tier of protection.
Here are our Apache authentication options then, from weak to most secure …
- cPanel's Password Protect Directories
Here's how to set up this control panel option:
- Browse to the target directory in cPanel's File Manager, right-clicking and choosing Password Protect (or instead click through the panel icon, if you like).
- Select the checkbox and give the directory a name to appear on the authentication – the login – screen.
- Save and you are redirected to a confirmation page.
- Click back to the previous page and add a username and password that gives access to the folder.
- Save the newly authorized user.
Now you can surf to that folder or to a file within, are asked for credentials and can log in.
So what did we really just do there? Clicked on some shiny icons, added some details, and cPanel interacted a bit over far too many pages. Let's get geeky, it's worth it.
- Authentication with mod_auth
When we protect a folder, as we did previously, cPanel uses Apache's mod_auth module to amend or create two hidden files, htaccess and passwd. htaccess lives in the folder to protect and passwd lives safely above the web root in the hush-hush htpasswd directory.
Using an example file, we can compare our control panel actions with those using the terminal, interacting directly with mod_auth. Cue screenshots, using cPanel we did this:
And mod_auth creates the ruleset in the htaccess file which, equally, we could just type:
Then we did this:
And mod_auth yawns a bit while it adds credentials to the password file:
Now then. Two points. First, with the syntax learned or duplicated, it's quicker to bin the middleman and just use the shell. More importantly, by dealing directly with Apache we have a better array of security tools. To clarify, let's take this a step at a time.
The htaccess file
Before we look at the mod_auth syntax that goes in htaccess files, let's give these administrative files a closer look.
Here at wpCop, we've met the hidden htaccess file already, and will do again. Essentially, it's a convenient and versatile web page configuration file that can be added to multiple directories, each file directing only its directory and that directory's sub-directories (the directory tree).
The directives these files contain can equally be placed in other site configuration files such as a website's virtual hosts file (which is tidier, all those directives from htaccess files being in one place). Uniquely, however, rules added in htaccess can be parsed immediately or, in other words, without the need to restart Apache. Feel the power!
Now back to using htaccess to store that mod_auth syntax …
Pretty basic then and more on that later. For when we navigate to the authenticating login page we want some kind of instructional message:
Now the link to the directory's corresponding password file:
And we'll specify to give access only to users recorded in the password file:
So far so good. Carry on.
The passwd file
Often also referred to as the htpasswd file, here's the syntax it houses:
johndoe is the authorized, or required user. L9c7m/hO16slA is the encrypted form of hackth!s, John's password. We use a handy tool, also called htpasswd, to encrypt that pass. Add as many usernames and passwords as you like to this file, each on a new line. The file itself can live and be called wherever and whatever you like as long as the AuthUserFile directive corresponds. One thing though: the file should be located above your web root.
Creating and editing password files
For terminal types with root access, creating a password file involves a simple command:
Let's break that down:
- htpasswd is the program doing the work
- -c is the option to create a new file or overwrite an existing one (Easy tiger!)
- ~/ is the equivalent of saying /home/USERNAME, importantly placing the file above your web root (which will be something like /home/USERNAME/public_html)
- . denotes the file to be hidden
- passwd is the name of our new hidden password file
- mary-beth is our user with a very pretty name
Having executed the command you are prompted to enter and confirm a password for Mary-Beth. Were you to submit hackth!s, upon opening the file, you would see:
Now, let's say you want to add someone else. Just drop the -c option and make sure you do, otherwise you will overwrite the existing file:
And, giving a password when prompted, someone else is listed too:
Now, you may be wondering, what really is the advantage of editing files manually, because so far, the only saving is a few cPanel page loads. Fair point. Read on.
Creating group membership
Let's say you have a few users requiring access to various directories. For example, you may have several client zones. You need access to each, but want to allow clients to access only their files. Other people need access to some, but not to all of these places.
Using the control panel, again we would choose to password protect a particular directory, this time adding privileged users. We would laboriously create users, often the same ones and we have to remember their passwords each time, for each directory. Behind the scenes, meanwhile, there are individual htaccess files for each directory to protect, each calling a separate password file.
Similarly, using the command line, we could have separate password files for each zone but, as we may surmise, this is a bit complicated.
More efficient is to use an online htpasswd generator, manually creating the file, else using the htpasswd tool from the command line to create a single password file in our home directory. This should be cross-referenced by a manually created group file, the two files being called by each protected directory's htaccess file. Sounds complex? It isn't. Here's the controlling htaccess ruleset:
The fundamentals are the same, except that now we are allowing access only to users within the single password file that are cross-referenced from the group whatnot which, in turn, is listed in the single groups file, htgroup. The htpasswd file is familiar to us already:
And the group file looks like this, one group per line designating our authorized users:
So we have added three groups manually, each with their own members whose credentials are cross-referenced from the password file.
Want another protected directory, and maybe another group? Simply add the htaccess referencing the group and add the group and its members to the groups file. If any users are new then add them to the password file.
So, whereas via cPanel we have password files for each directory, often duplicating users and their passwords, now we have a single password file to correspond with a single groups file. Much tidier and far more easily managed.
But still, we have not arrived at the crux of why this manual editing is better. Trust me.
Basically, it's basic
The thing is, mod_auth's basic protection is ultimately, well, not properly protective. Basic encryption churns up passwords on the server but sends them in plaintext not only when first logging in but with every subsequent page request and, as such, is especially vulnerable to packet sniffing. Well-versed hackers may tell you this is about as safe as a Bernie Madoff investment plan.
Used with SSL – in other words using https not http as wpCop covered in WordPress Administration Using SSL – then yes, the session sniffing problem is put to rest. Other issues remain though, such as if your server is compromised via creaky code. Given that scenario, the mod_auth security worry shifts to its weak key encryption. Basically, it lacks teeth (as we shall see).
What we have gained, however, is an overview of mod_auth and its related files that can be taken to more advanced, syntactically similar modules. We'll pass on a couple of these, instead consuming the ripe pick of Apache's key-bearing crop, mod_auth_digest.
- Better passwords with mod_auth_digest
mod_auth_digest is less popular than its ailing older brother, mod_auth. That's because, as with other more advanced Apache password modules, it's not a cPanel option. This is a shame, or is that a sham?
Decent hosts do, however, have digest enabled and, while still not bundled into cPanel, it is then available to use via the terminal. So what's the difference? Digest is far more secure. The scoop is that passwords remain puzzled in transit and encryption is nasty. Compare a basic-encrypted password …
… to its equivalent with auth_digest …
One small caveat. Some senile browsers, including IE6, won't support it, at least without workarounds. Nowadays this is barely an issue but here's the spiel:
Let's set it up.
Those with a VPS or dedicated box will need to enable the module and restart Apache:
Its use is strikingly similar to that of mod_auth. To create the password file we do this:
- htdigest is the password creation tool, using MD5 encryption
- -c is the option to create a new file or overwrite an existing one, so be sure to exclude this if you want to add a user without deleting a pre-existing file
- ~/ is the equivalent of saying /home/USERNAME
- . denotes the file should be hidden
- htdigest_pw is the name of our new hidden password file
- realm is a new variable here but is actually the same as basic's AuthName
- username is the user to whom you wish to give access
So to create a new auth_digest password file with a user called bobcat and a realm of “Beware of the dog!”:
Note that we have added “quotes” around the realm because there is more than one word. The password file looks like this:
So there are three sections rather than two, the middle one containing the realm name and each separated by a colon. (Ruddy syntax, huh!)
Fortunately again, the code for the accompanying ruleset is familiar and can be placed, for instance, in the htaccess file:
Easily digestible groups
As with Basic, adding groups with auth_digest requires manually creating the file so, here for example, we'll echo a group with two members to a new file:
The ruleset for their group, accommodating the new variable, must be changed to this:
The directive AuthDigestGroupFile points to the groups file and that of Require now says that only the admin and group users are privileged.
- More Apache authentication modules
Apache's modular framework makes it easy to add or remove tools and a choice of modules can often be found to perform any given task.
Password protection is an area with a legion of choices. We have covered mod_auth because it is the basis of Apache authentication, is easily used and, being the simplest to understand, makes for a good introduction to related authentication modules. We have covered mod_auth_digest because it provides better security and is arguably best of breed for most of us.
There are more.
Short of confusing the issue with further authentication modules, which by and large, work the same way as mod_auth and mod_auth_digest it would, nonetheless, be amiss not to mention a few of them.
mod_auth_db & mod_auth_dbm
Two very similar authentication modules, auth_db and auth_dbm differ from regular auth and auth_digest by storing passwords in database files (db and dbm files) rather than in a regular text file. This has a great benefit: speed of data retrieval. If you have thousands of users and passwords, rather than Apache having to sift through one line at a time, this is an option to explore.
Another database-driven authentication system, auth_mysql is a trifle trickier to set up as it involves creating a basic MySQL database. Then again, our WordPress databases are infinitely more complex so there's no real excuse there.
Again the syntax is very similar to the above systems. The exception is that this record must additionally stipulate database details for Apache to make a connection with MySQL:
For those with thousands of users to data-crunch – and bearing in mind we know MySQL already and perhaps use phpMyAdmin too – mod_auth_mysql is the way to go.
Quick note for those for whom MySQL just doesn't quite cut the mustard, instead having defected to PostgreSQL: rather than mod_auth_mysql, use mod_auth_pg95. Again, similar syntax et cetera-ra-ra-de-ra.
Yet more authentication methods
Yes there are but the worthwhile alternatives to what wpCop has covered require additional servers to run and, besides, aren't you getting just a tad bored of this tutorial?
Best advice: Digest for most of us and MySQL for empires.
Serving up security
One could argue that wpCop's Web section is the most important area of this site. Then again, you could argue that about each and every section, depending on your point of view. For sure though, the web is doggone dangerous so, if it weren't for the fact that most of us are here to secure WordPress, it seems to me, it would be.
The last few tutorials here have introduced us to the server. This very last guide was relatively taxing, even, so the good news is that if you only kind of semi-understand this topic then the early server guides are going to be an easy cruise.
Enough spiel. Let's secure the WordPress server …