Simple access restriction using a password. Alternative password storage
It is often necessary to restrict user access to certain areas of your site. For example, to the administrative part. This is often done by creating your own authorization mechanism. However, there is a way to protect areas of the site using built-in server and browser tools. The simplest authorization is called Apache Basic authorization. This will be a long article, so be prepared for a lot of reading. But it will contain everything you will ever need to work with this type of authorization.
How it works
First, we put the .htaccess file on the server. In it we indicate which zone (or specific file) we want to password protect. It might look something like this:
AuthType Basic #authorization type
AuthName "Name" #authorization name
#location of the password file
AuthUserFile /usr/host/mysite/.htpasswd
#skip any user,
#who entered the correct username and password
require valid-user
In addition, the site may contain a password file. It has a simple structure:
login:encrypted password
login:encrypted password
...
The path to this file is specified in htaccess.
Conversation with a server under a magnifying glass
Now let's assume that someone typed in the address of a password-protected directory. What will happen? Here's what:
1.
The browser asks the server for a page at http://site/secret.
The server sees that this page is protected. It sends the browser headers:
WWW-Authenticate: Basic realm="My Realm"
Status: 401 Unauthorized
HTTP Status: 401 Unauthorized
Here it must be said that the zone (realm) - important parameter. If you need to guide the user through several password-protected zones, not all of which the user should have access to, then the name of the zone will determine whether the user is logged in to this place or not.
2. Having received these headers, the browser draws a login and password request form on the screen. If the user clicks "Cancel", the browser displays all the data that followed these headers.
3. If the user has entered a login and password, they are sent to the server. He goes into the file with passwords and looks at the following pair there. If it finds it, it sends back the page that the browser requested at the very beginning. If not, it sends authorization headers again.
4. If the user entered the correct login and password, and the server responded with the requested page, the browser remembers the entered login and password for this zone.
5. Then, if the browser sends any (!!!) request to the server, it attaches a pair to it - login and password. It looks like this:
Authorization: Basic base64(login:pass)
That is, the login-password pair is encrypted in base64. Let me draw your attention once again - the login and password are now sent with any browser request. For pictures, style files, scripts, favico and everything else. Essentially, to receive each file, you go through authorization. Only the browser does this for you.
6. When the server receives a request, it checks to see if it also comes with a login and password. If they do, they immediately check for authorization.
Authorization request in Perl and PHP
Now it’s time to figure out how to display the Apache authorization window not using htaccess, but using a script in Perl or PHP. I specifically put these two solutions on two different languages under one heading. Because now, knowing the mechanics, we can quickly come to the conclusion that in order for the authorization request window to appear, we only need to send necessary headers. This is what we will do.
#Perl
print "WWW-Authenticate: Basic realm=\"My Realm\"\n";
print "Status: 401 Unauthorized\n";
print "HTTP-Status: 401 Unauthorized\n";
print "Content-type: text/html\n\nCancel";
#PHP
header("WWW-Authenticate: Basic realm=\"My Realm\"");
header("Status: 401 Unauthorized");
header("HTTP-Status: 401 Unauthorized");
print "You clicked Cancel";
The result in both cases will be an authorization request form.
Intercepting authorization in Perl
Let's say the user has entered a username and password. They are sent to the server. But here a problem arises. The fact is that when Apache receives a login and password, it wants to check them in the password file. But what if logins and passwords are stored not in a password file, but in a database? In this case, you need to authorize the script before Apache does it.
A difficulty arises: Apache does not pass the entered login and password into environment variables. That is, accessing them from Perl is problematic. But probably. The simplest solution is to use mod_rewrite. Add in htaccess file lines:
RewriteEngine on
RewriteCond %(HTTP:Authorization) ^(.*)
RewriteRule ^(.*) —
They will add a new environment variable. From Perl it will be visible as $ENV(HTTP_CGI_AUTHORIZATION). It will contain a login-password pair encoded in base64. Of course, you'll have to tinker a little to recode them back, but that's something. Moreover, there is, in fact, not much fuss there:
$ENV(HTTP_CGI_AUTHORIZATION) =~ s/basic\s+//i;
my ($REMOTE_USER,$REMOTE_PASSWD) = split(/:/,decode_base64($ENV(HTTP_CGI_AUTHORIZATION)));
Now we have two variables $REMOTE_USER and $REMOTE_PASSWD, with which you can authorize using the script, checking the login and password with whatever your heart desires.
Intercepting authorization in PHP
Session support in Perl and PHP
Among other things, after authorization is successful, the environment variable will contain the login of the authorized user, which calls the executable script. That is, you will always know who exactly launched the script. The login is contained in the variables:
#perl
$ENV(REMOTE_USER)
#php
$_SERVER
That's it
The article turned out to be great, as I promised. But it examines the basic principles of how Apache base authorization works, and also contains solutions to some problems that may arise when working with it. To be honest, I spent more than one hour looking for answers to some of the questions resolved in this article. I hope it will help save time for other programmers.
Related links
- htaccess and htpasswd - how to authorize only Apache
- htaccess.net.ru - a site dedicated to the possibilities of server management using htaccess files
In addition to these modules, there is also mod_authn_core and mod_authz_core. These modules implement the core directives that are core to all auth modules.
You probably also want to take a look at Access Control, which discusses various ways control access to your server.
Introduction
If you have information on your website that is sensitive or intended only for a small group of people, the techniques in this article will help you make sure that the people who see those pages are the people you intended them to see.
This article looks at the "standard" way to secure parts of your website that most of you are going to use.
The note:
If your data really needs to be secure, consider using mod_ssl in addition to any authentication.
Prerequisites
The directives discussed in this article will need to be sent either to your main server's configuration file (usually under
If you plan to use .htaccess files, you will need to have a server configuration that allows authentication directives to be set in these files. This is done with the AllowOverride directive, which specifies which directives, if any, can be placed in the per-directory configuration files.
Since we're talking about authentication here, you'll need an AllowOverride directive like this:
AllowOverride AuthConfig
Or, if you are simply going to specify directives directly in the main server configuration file, you will of course need to have write permission to that file.
And you need to know a little about your server's directory structure to know where some files are stored. It doesn't have to be terribly difficult, and I'll try to figure that out as we get to this point.
You also need to ensure that the mod_authn_core and mod_authz_core modules have either been built into the httpd binary or loaded by the httpd.conf configuration file. Both of these modules provide core directives and functionality that are critical to configuring and using authentication and authorization on a web server.
Getting a Job
Here are the basic principles for password protecting a directory on your server.
First, you need to create a password file. Exactly how you do this will depend on which authentication provider you choose. More on this later. To begin with, we will use a text password file.
This file must be placed somewhere inaccessible from the Internet. This means that people cannot download the password file. For example, if your documents are served from /usr/local/apache/htdocs , you might want to place the password files in /usr/local/apache/passwd .
To create the file, use the htpasswd utility provided with Apache. This will be located in the bin directory wherever you installed Apache. If you installed Apache from a third party package, this may be in your execution path.
To create the file, enter:
htpasswd -c /usr/local/apache/passwd/passwords rbowen
Providing more than one person with
The above directives only allow one person (specifically, someone with the username rbowen) to enter the directory. In most cases, you will want more than one person's AuthGroupFile. This is where AuthGroupFile is located.
If you want to include more than one person, you need to create a group file that associates group names with a list of users in that group. The format of this file is quite simple and you can create it using your favorite editor. The contents of the file will look like this:
GroupName: rbowen dpitts sungo rshersey
This is just a list of group members in long line, separated by spaces.
To add a user to an existing password file, enter:
htpasswd /usr/local/apache/passwd/passwords dpitts
You will get the same response as before, but it will append to the existing file rather than creating a new file. (This -c makes it create a new password file).
Now you need to change the .htaccess file or block
AuthType Basic AuthName "By Invitation Only" # Optional line: AuthBasicProvider file AuthUserFile "/usr/local/apache/passwd/passwords" AuthGroupFile "/usr/local/apache/passwd/groups" Require group GroupName
Now anyone who is listed in the GroupName and has an entry in the password file will be included if they enter the correct password.
There is another way for multiple users to be less specific about this. Instead of creating group file you can simply use the following directive:
Require valid-user
Using this rather than the Require user rbowen line will allow anyone listed in the password file to enter their password correctly.
Possible problems
Because of the way Basic authentication is specified, your username and password must be verified every time you request a document from the server. This is even if you reload the same page and for every image on the page (if they come from a protected directory). As you can imagine, this slows things down a bit. The amount it slows down is proportional to the size of the password file, because it has to open that file and go through the list of users until it gets your name. And it should do this every time the page is loaded.
The consequence of this is that there is a practical limit to how many users you can put in a single password file. This limit will depend on the performance of your specific server, but you can expect a slowdown after receiving a few hundred entries and may want to consider a different authentication method in the meantime.
Alternative password storage
Since storing passwords in text files has the problems noted above, you may want to store your passwords in another location, such as a database.
Using Multiple Suppliers
With the introduction of the new provider-based authentication and authorization architecture, you are no longer locked out of any authentication or authorization method. In fact, any number of providers can be mixed and matched to provide you with the exact scheme that suits your needs. IN following example Both file-based and LDAP authentication providers are used.
In this example, the file provider will first attempt to authenticate the user. If it cannot authenticate the user, the LDAP provider will be called. This allows you to expand the scope of authentication if your organization implements multiple authentication stores. Other authentication and authorization scenarios may involve mixing one type of authentication with another type of authorization. For example, authentication against a password file that is authorized against an LDAP directory.
Just as multiple authentication providers can be implemented, multiple authorization methods can be used. This example uses file group authorization as well as LDAP group authorization.
To take authorization a little further, permissions container directives such as
In addition to just authorization
Applying logic and ordering
Controlling how and in what order authorization will be applied has been a mystery in the past. Apache 2.2 introduced a provider-based authentication mechanism to separate the actual authentication process from authorization and support credentials. One side benefit was that authentication providers could be configured and called in a specific order, which was independent of the order in which the auth module itself was loaded. This same provider-based mechanism has also been carried over to authorization. This means that the Require directive not only specifies which authorization methods should be used, but also specifies the order in which they are called. Several authorization methods are called in the same order in which the Require directives appear in the configuration.
With the introduction of authorization container directives such as
Authentication caching
There may be cases where authentication places an unacceptable burden on the provider or your network. This will most likely affect users of mod_authn_dbd (or third party/custom providers). To deal with this, HTTPD 2.3/2.4 introduces a new caching provider, mod_authn_socache, to cache credentials and reduce the load on the origin provider(s).
This can significantly improve productivity for some users.
More information
You should also read the documentation for mod_auth_basic and mod_authz_host which contain more information on how this all works. The directive can also help simplify certain authentication configurations.
The various ciphers supported by Apache for authentication data are explained in section "Password Encryption".
And you might want to take a look at Access Control, which discusses a number of related topics.
If you want to let more than one person in, you"ll need to create a group file that associates group names with a list of users in that group. The format of this file is pretty simple, and you can create it with your favorite editor. The contents of the file will look like this:
GroupName: rbowen dpitts sungo rshersey
That"s just a list of the members of the group in a long line separated by spaces.
To add a user to your already existing password file, type:
htpasswd /usr/local/apache/passwd/passwords dpitts
You"ll get the same response as before, but it will be appended to the existing file, rather than creating a new file. (It"s the -c that makes it create a new password file).
Mod_auth_basic and mod_authz_host which contain some more information about how this all works. The directive can also help in simplifying certain authentication configurations.
The various ciphers supported by Apache for authentication data are explained in Password Encryptions.
And you may want to look at the Access Control howto, which discusses a number of related topics.
Here I will talk about Apache's capabilities to protect the contents of the server or parts of it.
Apache Directives for Access Control
IP control
If you just need to allow or block access to some part of the site or the entire server for certain IPs, use the following directives.
Attention! If you want to use these directives in your .htaccess file, make sure that the AllowOverride directive in your Apache root configuration file includes the Limit option for your host.
Values: Order (allow,deny | deny,allow)
The Order directive specifies the order in which the Allow and Deny directives will be read
- Allow, deny - Allow directives are read first. If the user is not on this list, then he is blocked. If it exists, then Deny directives are read (the process is not yet completed). If the user is there too, then he is blocked. If it is not there, then it is skipped. That is, the user is skipped only if he is in the Allow list, but not in Deny
- Deny,allow - first Deny directives are processed and those users who are in this list are eliminated. Any others are skipped. That is, the user is always skipped, but if he is not in the Deny list
Allow and Deny
Directive format: (Allow | Deny) from (IP | IPs | all) (IP | IPs | all) : (IP | IPs | all)
The Allow and Deny directives determine which clients are allowed or denied access to the server.
The directives allow the use of:
- Single IP(IP) - normal look IP, for example 127.0.0.1
- IP groups (IPs) - IP group, for example, for access only from the local network, 192.168.1.0/24
- Any IP(all) - means any IP
The word from can be followed by any number of specified directives, separated by a space
Examples
File.htaccess
Order allow,deny # Deny from all # if you write this, then even those addresses # specified in the Allow directives will not be skipped Allow from 192.168.1.0/24 11.11.11.12
This file specifies access only for clients from the local network or with IP 11.11.11.12
Part of the httpd.conf file
...
So we ban a site for any one IP
Control by username or group
If you need to protect a site or part of a server with a password, use the following directives.
Attention! If you want to use these directives in your .htaccess file, make sure that the AllowOverride directive in your Apache root configuration file includes the AuthType option for your host. Also, some directives (AuthUserFile and AuthGroupFile) require mod_auth support
AuthType
Values: AuthType (Basic | Digest)
Apache supports 2 types of content protection (AuthType directive):
- Basic - basic authorization. Encryption is used on both sides, but the client transmits the password not securely encrypted, because the encryption key is not used. This is a major drawback of this method. Base64 encryption algorithm is used
- Digest - authentication special code(digest) that uses the key, specifically the username, password, area requiring authentication, various information about the request and unique code of this request, which Apache assigns to each connection. This is a one-way method, and it would require an outsider to have too much information about both parties to decipher it. But the main disadvantage of this method is that not a single user browser supports it, although this is probably no longer the case (data as of 2000). This method is usually used in specialized systems
AuthName
Directive format: AuthName "String"
This directive specifies the hint text that is displayed in the browser when entering a secure part of the site, see the figure above
AuthUserFile, AuthGroupFile
Directive format: (AuthUserFile | AuthGroupFile) "String"
Attention! For these directives to work, the Apache mod_auth module is required, which is enabled by default
These directives define, respectively, the path (absolute) to the file storing bundles Name:DES and the path (also absolute) to the file storing bundles Group:Name Name: Name
AuthUserFile
Contains information about valid usernames and their passwords in the format Name:DES, where DES is the name of the encryption algorithm. The file can be created using the standard console program included with Apache, htpasswd. See below for a description of its use.
AuthGroupFile
This directive only needs to be specified if you have specified a value for the Request directive (see below) equal to group
This file contains information about valid user groups to log in to. File format: Group:Name Name: Name. That is, only those users who exist and who belong to the groups described in the Require directive (see below) will be able to log in
Values: Require (user Name Name: Name | group Group Group: Group | valid-user
This directive defines the authentication principle:
- User - only users specified next, separated by a space, and who have specified the correct password, will be able to log in
- Group - only users who are members of the groups specified next, separated by a space, and who have specified the correct password, will be able to log in. Specifying the AuthGroupFile directive is required
- Valid-user - any user existing in the AuthUserFile file and specifying the correct password will be able to log in
This concludes the directives required for the AuthType Basic method. I will not list other directives related to the AuthType Digest method, since they have a narrowly targeted effect and shared systems not used
Apache htpasswd utility
This console program creates files specified in the AuthUserFile directive. The file stores the links Name: Password for access to the protected part of the site
Usually the program comes with Apache and is located in the bin folder of its root folder
Utility call format:
Htpasswd [-cdpsb] Path to the Password FileName of the Required User
Command Line Options
- -s - create new file. If this parameter is not specified and the file does not exist, the utility will generate an error and crash. Attention! If the file already existed, it will be overwritten
- -d - the utility will use the DES encryption algorithm (in C this is the crypt() function). By default it is used in all OS, but not in Windows
- -m - use MD5 encryption algorithm, which is the default cipher in Windows
- -p - save the password in its pure form, without encryption. Works only on Windows
- -s - the utility will use the SHA encryption algorithm
- -b - in normal mode Without this option, the utility receives the password by entering it on standard input. When using this option, the path to the password file must be followed by a password, and the utility will obtain the password from this option. The utility will not wait for user input; it will immediately return control to the shell. Example: htpasswd -b .htpasswd smhtpass
Password examples
File.htaccess
AuthType Basic AuthName "You are entering Private area. Please enter your login and password" AuthUserFile /home/Site.ru/www/PrivateDir/.htpasswd # AuthGroupFile .htgroup # this directive is not needed here, # because we use authentication by to users, but not by groups Require user My root UUCP hacker guest
Here access is allowed via the .htpasswd file for My, root, UUCP, hacker and guest users. Authorization type Basic
Part of the httpd.conf file
....
Here access is allowed to the same file with users, but only those who are members of the my or root groups defined in the .htgroup file
To create a password file for the first example
We enter the shell and write the following commands
; We assume that the current folder is set to the folder with the htpasswd utility; We also assume that the password file that needs to be created does not yet exist # htpasswd -cb /home/Site.ru/www/PrivateDir/.htpasswd root rootpasswd # htpasswd -b /home/Site.ru/www/PrivateDir/. htpasswd UUCP pass_rootcp # htpasswd /home/Site.ru/www/PrivateDir/.htpasswd My Password: mypasswd Repeat password: mypasswd Password created OK ; Similarly, we create entries for hacker and guest users
Conclusion
This is where I will finish my description of data protection tools here. Apache web server. All wishes or questions can be left at the following coordinates
On given time(July 2006) I am writing a Content Managing System (CMS) for PHP 4+, MySQL 3.23.xx+ and Apache 1.3+, everyone who wants to watch or join - write to me here
When you run your own website, there are likely to be areas that you want to restrict access to for visitors. Web applications have their own authentication and authorization methods, but the web server itself can be used to deny access if other methods fail necessary requirements or unavailable.
From this article you will learn how to set up authorization using a password on Apache web server running on Ubuntu 16.04.
Requirements
Before proceeding with the next steps, make sure you have access to the Ubuntu 16.04 server.
You will also need the following to complete the instructions:
- a user who can run sudo commands on your server;
- Apache web server;
- a site on which an SSL certificate is installed (for example, Let’s Encrypt).
If you have all of the above, then log in to the server as a user with sudo rights and proceed to the first step.
Step 1: install the package with Apache utilities
You will need a utility called htpasswd, which is part of the apache2-utils package. This is used to create the file, as well as the username and passwords that will be used to access the restricted view. ordinary users content.
Enter the following commands:
$ sudo apt-get update $ sudo apt-get install apache2-utils
Step 2: create a file with passwords
Now you can use the htpasswd command. Using it, you will need to create a file with passwords that Apache will use to authenticate users. For these purposes you should create hidden file called .htpasswd inside the settings directory /etc/apache2.
The first time you use this utility, you will need to add the -c switch to the command in order to create specified file. Also at the end of the command you need to specify the username ( sinatra V in this example) - this is necessary in order to create new entry inside the file:
$ sudo htpasswd -c /etc/apache2/.htpasswd sinatra
You will be asked for a password and confirmation for the created user.
If you want to add any other users (for example, another_user), use the same command, but without the -c switch:
$ sudo htpasswd /etc/apache2/.htpasswd another_user
Look at the contents of this file:
$ cat /etc/apache2/.htpasswd
You will see the username and encrypted password for each entry:
Output sinatra:$apr1$.0CAabqX$rb8lueIORA/p8UzGPYtGs/ another_user:$apr1$fqH7UG8a$SrUxurp/Atfq6j7GL/VEC1
Step 3: Set up password authentication on Apache
You now have a file with usernames and passwords in a format that Apache can read.
The next step is to configure Apache to check this file whenever it is about to grant access to a protected file. prying eyes content. You can do this in two ways: either directly in the site's virtual host file, or by adding .htaccess files to the directories to which you want to restrict access.
In general, it is better to use the first option, that is, use a virtual host file. However, if you need to give non-privileged users the ability to manage their own access restrictions, enforce version control restrictions in the same way as on the site, or have web applications that already use .htaccess for other purposes, you might want to go with the latter ways.
That is, choose the path based on your requirements.
Path 1 (preferred): configure authorization via virtual host
The first way is to edit Apache settings and add password protection to the virtual host. This will also improve performance because it eliminates the need to read distributed settings files. This path requires access to settings, which is not always available, but if you have access, then this path is preferable.
To begin, open the virtual host file that you want to restrict access to. As an example, this tutorial will use the 000-default.conf file, which contains the default virtual host installed using the Apache package on Ubuntu.
$ sudo nano /etc/apache2/sites-enabled/000-default.conf
Inside, the file with uncommented lines will look something like this:
Authentication occurs based on directories. In order to set up authentication, you need to place the directory to which you want to deny access in a block
Inside the directory block, specify that you want to set up Basic authentication. For the AuthName column, you must select the name that will be displayed to the user when requesting authentication data. In the AuthUserFile column, you must specify the file with the password that was created earlier so that Apache can find it. You will also need a valid-user who can access the data; in other words, anyone who can confirm their identity using a password will be allowed into the directory.
After editing, save and close the file.
Before rebooting the server, check your settings next command:
$ sudo apache2ctl configtest
If everything is fine and you see Syntax OK, then reboot the server for the new password-required access policy to take effect. To do this, enter the following commands:
Now the directory you designated earlier is password protected.
Apache can use .htaccess files to give access to some settings that you can set through the content directory. Since Apache will access the contents of these files on every request that contains this catalog, which can negatively affect performance, the first way is preferable, but if you already use .htaccess files, or you need unprivileged users to be able to independently manage access restrictions, then in this case the use of .htaccess files is clear and logical.
To enable password protection using .htaccess files, open the main configuration file Apache:
$ sudo nano /etc/apache2/apache2.conf
Next, find the block
. . .
After this, save and close the file.
Now you need to add a .htaccess file to the directory you want to restrict access to. In this tutorial, as an example, access will be denied to the entire document root directory (that is, the entire site), which is located at /var/www/html, but you can place this file in any directory that you want to restrict access to:
$ sudo nano /var/www/html/.htaccess
Inside this file, specify that you want to set up Basic authentication. For the AuthName column, you must select the name that will be displayed to the user when requesting authentication data. In the AuthUserFile column, you must specify the file with the password that was created earlier so that Apache can find it. You will also need a valid-user who can access the data; in other words, anyone who can confirm their identity using a password will be allowed into the directory:
AuthType Basic AuthName "Restricted Content" AuthUserFile /etc/apache2/.htpasswd Require valid-user
Save and close the file. Reboot the server for all changes regarding password protection of the selected directory to take effect. Then use the systemctl status command to ensure the reboot was successful:
$ sudo systemctl restart apache2 $ sudo systemctl status apache2
Step 4: check for authentication protection
To make sure your data is protected, try accessing it in a browser. You should be presented with a window asking for your username and password, which will look something like this:
If you enter the correct data, you will be able to see the requested data. If you enter incorrect information or click Cancel, you will see an error page (Unauthorized), which indicates that access is denied to unauthenticated users:
Conclusion
If you have completed all the steps listed in this guide, your site now has basic authentication. However, don't forget about other ways to protect against unauthorized access to your data, such as SSL certificates and using SSH.