Protecting Your Site with Access Controls
If you are wondering how I managed to get the Base64 equivalent of my user name, password combination, it was with the help of the following one-line Perl program:
perl -e 'use MIME::Base64;\ print encode_base64("reuven:password");'
Entering the above in the shell results in:
cmV1dmVuOnBhc3N3b3Jkwhich must have been the Base64 equivalent of reuven:password, because it allowed us access to the resource.
MIME::Base64 is a Perl module that you can get from CPAN (http://www.perl.com/CPAN/) for handling MIME-standard mail. I cannot remember the last time that I had to write a program to handle e-mail encoded with MIME, but the Base64 module comes in handy for non-mail applications such as this one.
If you have any experience with securing computer networks, you might be surprised to learn that user names and passwords are passed between web browsers and servers unencrypted. Indeed, while the text isn't passed completely in the clear, it would require another one-line Perl program to turn the Base64-encoded user name, password string back into its ASCII original.
Suffice it to say that this is not a very secure scheme. Someone monitoring packets sent over the network would have to work a bit harder in order to capture your user name and password, but not significantly harder than if the text were sent without any transformation.
At the very least, make sure to use user names and passwords that have nothing to do with /etc/passwd, the file that typically stores user information on Linux systems. Your secret documents can still be available via the Web, but your machine will not be open to break-ins which are a much more serious threat. (Someone who breaks into your computer can do much more than just read your documents.)
An authentication scheme known as “Digest” will soon be available. It is already available in Apache and is waiting for a browser to implement it. The digest method applies a function to a number of parameters, including the user name and password that are going to be sent, and a number generated by the server that is sent as part of the headers in the 401 -- Authorization required response. The result of the digest function is then sent over the network, rather than the user name and password themselves. This is not a foolproof system, but it is far better than the current situation in which your passwords are easily available.
Now that we have discussed the theory behind all of this, we will take a look at what is necessary to protect directories on your server.
The first thing you need is a file in which user names and passwords can be stored. Apache comes with a program, htpasswd which can be used to create and modify such files. The syntax is fairly simple:
htpasswd [-c] passwordfile username
To create a new password file (or overwrite an existing one), use the following syntax:
htpasswd -c /etc/httpd/conf/passwords reuvenIf you enter the above line at the Linux shell (with htpasswd in your $PATH environment variable), you will be prompted for a password. After you have entered the password twice, the user name, password pair will be stored in the file you specified.
The -c option creates a new file or overwrites an existing one. (This option is unnecessary to create a user; you can do that without the -c option, as described below.) Be especially careful with the -c option, because it overwrites old versions of the password file without warning or making backups.
To add a user to an existing password file or to change the password of an existing user, invoke htpasswd without the -c option:
htpasswd /etc/httpd/conf/passwords reuven
Regardless of whether you are adding a new user or changing an existing user's password, you will be asked to enter the user's password twice. When you have done that, the named file will be updated.
The password file contains nothing more than names and encrypted passwords in the format:
username1:password1 username2:password2 username3:password3
For example, the password file that I created for this column contains the following entries:
reuven:zZDDIZ0NOlPzw reena:SjCCCbsjjz2Z2 foobar:RpubVfdhWwv1UIf you expect to handle many authorized user requests on your system and if the number of users on your server is high, you might want to consider using authorization using a more efficient system, such as DBM or DB. Support for DB and DBM are available for modern versions of Apache (although the appropriate module must be compiled in), as is support for a number of relational databases, including Msql and MySQL. More information on these options is available on the Apache web site.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Hacking a Safe with Bash
- Django Models and Migrations
- Secure Server Deployments in Hostile Territory, Part II
- Huge Package Overhaul for Debian and Ubuntu
- Home Automation with Raspberry Pi
- The Controversy Behind Canonical's Intellectual Property Policy
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- diff -u: What's New in Kernel Development