Username-Password Authentication - Online Article

The first major element of Web server security is username/password  authentication. I kick off this discussion  by looking at what the Web browser user sees when he encounters  a Web page that requires username/password authentication for  access.

To make this more understandable, look at an example. Suppose  your httpd server's DocumentRoot directory contains three main subdirectories, named public, management, and personnel.  Using your GACF, you can specify that access to the management and personnel subdirectory  trees requires username/password authentication, while public is left wide open for anyone to access without being prompted  for a username and password. You can also set up LACFs within  the protected subdirectories to further limit access to particularly  sensitive documents by using usernames/passwords.

Setting Up Username/Password Authentication in a Netscape  Server

The Netscape  servers actually use the Netscape browser itself as a graphical  interface for administering the server, providing a set of private  Web pages and configuration scripts to do so. Using the Server  Manager page, you can easily enter new users and their passwords  into what Netscape calls the user database. (Your empty user database  must first be created before you can add any users and passwords  to it.)

After you've set up one or more users, you can continue to use  the Server Manager to apply access control rules to users. You  can associate groups of users together for purposes of authentication,  and define access control rules that apply to groups as well as  to individuals. With group access controls, users must still provide  their own usernames and passwords, but access to a specified area  of the server file tree (Netscape calls this a realm) can  be controlled by requiring that a user be a member of a group  for access. Even if a user provides the correct username and password,  he may be denied access based on group access control rules if  he is not a member of that realm's group.

Setting Up Username/Password Authentication in the CERN/W3  httpd Server

The CERN/W3 httpd server uses a UNIX-like password file (but with  only three colon-separated fields) containing usernames, encrypted  passwords, and users' real names. The password file is controlled  using the htadm program that  comes with the httpd server software. This program enables you  to create and delete user accounts, as well as change and verify  existing passwords. Although you can provide all the information htadm needs on the command  line, it's easier to let the program prompt you for it. For example,  to add a new username and password:

# path/to/htadm /path/to/passwordfile

You must specify the name of the password file on the command  line, but htadm will  prompt you for the function you want to perform and the actual  username, password, and user's real name, as appropriate. (You  can use multiple words in the realname field to include a full name and other information.) If you're  in a hurry or have a long list of users to add or delete, you  can take advantage of specifying all the htadm command-line arguments at once, like in these examples:

# htadm -adduser passwordfile joeuser  joespassword Joe User  # htadm -deluser passwordfile baduser

The first example creates the user joeuser with the password joespassword,  and the second deletes the user baduser.  This enables you to do mass account deletion using shell looping  and to take username, password, and real name input from a file.  You'll need something like the expect package to do automated, mass account creation. There are also -passwd and -check command-line arguments to htadm,  which enable you to change and verify passwords, respectively.

As with the Netscape server, the CERN/W3 httpd server also enables  you to associate individual users with groups. You can set up  group authentication rules in LACFs that control access to portions  of your Web server document tree. CERN/W3 uses a group file,  the format of which is based on the standard UNIX /etc/group format, but it has an added feature for defining access control  rules and for recursive inclusion of groups into metagroups. A  simple group file, which I'll use for examples in this article,  might be something like this:

management: tom, mary, joan  personnel: anne, joe, jerry  staff: management, personnel  public: All, Anybody

Here, four groups are defined. The first two each contain a list  of several individual usernames, but the last two are groups of  groups. (Two special groups, All, meaning all authenticated  users and Anybody meaning anyone, authenticated or not,  are predefined by the CERN/W3 httpd server software, and refer  to anyone who might access the server; see the server documentation  for details on the distinction between All and Anybody.)

After setting up your password and group files, you can add access  control protection to your server. As noted, high-level rules  go in httpd.conf, the GACF.  Access control rules in httpd.conf use the Protect directive  and associated protection rulesets. Here's a simple Protect directive, based on the group file shown above. It implements  the example division of your Web server's document tree into public, management, and personnel subtrees:

Protect /personnel/* Personnel

This example indicates that all subdirectories and files in the personnel subtrees of your  Web server DocumentRoot are  subject to the rules in the protection ruleset named Personnel.  (You can name protection rulesets with any name you want, but  it makes sense to use meaningful names.) According to this Protect directive, the ruleset itself also appears in the GACF, under the label Personnel,  and might look like this:

Protection Personnel {       AuthType     Basic         Passwordfile /usr/local/etc/httpd/passwd         GroupFile    /usr/local/etc/httpd/group         GetMask      personnel    }
Note
The Protect directive can specify the protection ruleset be read from a file, rather than from another part of the GACF. In this case, the directive would look like this: Protect /personnel/* /usr/local/etc/httpd/acls/Personnel Here, the absolute pathname to the file named Personnel (not relative to the server DocumentRoot) is specified. This example assumes you've created a special subdirectory (/usr/local/etc/httpd/acls) in which to store all   your access control information. If you use individual files like this to define your protection rulesets, you need not enter the curly braces that are required in the GACF.

This simple example applies username/password authentication access  control to all files and subdirectories in the personnel directory, using the following criteria, all of which must be  met before access is granted:

     
  • Users must enter a username and password.
  •  
  • Usernames and passwords are validated  against the file /usr/local/etc/httpd/passwd.
  •  
  • Authenticated usernames are checked for  membership in the group named personnel in the groups file /usr/local/etc/httpd/group.

Going back to the sample group file, you can see that only users  Anne, Joe, and Jerry will be granted access to files in this directory  tree. Even if Tom provides his correct password, he will not be  given access.

This has been a very cursory look at user authentication in the  CERN/W3 httpd server. Protect directives  and protection rulesets can be quite detailed, including other  features not described here. In addition, you can set up both  a default protection ruleset and progressively more limited protection  rulesets according to your own criteria, adding access control  all the way down to the individual file level. For details, see  the documentation which comes with the CERN/W3 httpd server software  (on the Developing Intranet Applications with Java CD-ROM).  Or check out the World Wide Web Consortium's online.

Setting Up Username/Password Authentication in the ncSA httpd  Server

The ncSA httpd server, along with those derived from it (WinHttpd  for Windows and the Apache package for UNIX systems), provide  similar username/password authentication mechanisms. Except where  there are differences among these packages, I'll discuss them  as a group.

Although these packages use authentication methods that are similar  to the methods used in the CERN/W3 httpd package, there are differences.  Let's first focus on the similarities. Most importantly, the ncSA  packages support both GACFs and LACFs, enabling you to set high-level  policy at the server level and then fine-tune it at the directory  and subdirectory levels. In addition, both individual user and  group authentication are provided for. Finally, some configuration  commands, such as AllowOverride,  affecting critical items listed earlier might only appear in a  GACF. You can also disallow the use of server-side includes and  the following of symbolic links, for example, as described earlier.

The GACF in the ncSA packages is the file named access.conf (access.cnf in WinHttpd)  and is located in the conf subdirectory of your Web server's file tree. On UNIX systems,  the server is usually installed in /usr/local/etc/httpd,  and on Windows systems, the server is in c:\httpd.  In both cases, there exists a conf subdirectory in the top-level httpd directory. However, the layout  and syntax of the access.conf file is significantly different from the GACF in the CERN/W3 httpd  server.

The ncSA file is divided into sections, one for each directory  to be controlled. Each directory section in access.conf looks something like this:

<Directory /absolute/directory/path>    [ Various configuration commands ]  </Directory>

Like HTML markup, each Directory (the literal word Directory must appear) section is marked off by the access.conf tags <Directory> and </Directory>, surrounded  with angle brackets. Case is not significant in the word Directory,  although it might be in the actual directory name.

The directory path here is an absolute pathname and is not relative  to either the Web server's ServerRoot or DocumentRoot directories.  If you use /usr/local/etc/htdocs/,  for example, you must specify it in full and not just simply use /htdocs. Within each Directory section of the file, you specify one or more options, or configuration  commands, which will be applied by the server to the specified  directory. There are a number of different options, but we're  concerned here with username/password authentication.

Of course, before you can apply a username/password access control,  you need to have established users and passwords on your server.  Usernames and encrypted passwords are stored in a special httpd  password file. ncSA provides a utility program, htpasswd,  for creating this file; you'll find it in the support subdirectory of your ncSA httpd server file tree, and you might  need to compile it. The syntax of the htpasswd command is substantially simpler than that of the CERN/W3 htadm command, as are its capabilities. To add a user to your password  file or change his password, use this syntax:

# htpasswd /path/to/passwordfile username

If you don't already have a password file, you need to modify  this command a bit:

# htpasswd -c /path/to/passwordfile username

The -c argument creates a  new password file, so you use it only once. If you use it again,  you'll erase your current password file. You can name your password  file anything you like.

You can't remove a user from your password file with the htpasswd command. Instead, you'll have to hand-edit the password file with  a text editor and delete the user's entry. The format of the file  is quite simple, with just two fields in each record, separated  by a colon:

tkevans:TyWhfX9/zYd7Y

The first field is the username. The second field is the encrypted  password. Permissions on the password file must be set so as to  be readable by the system user under whose userid the httpd server  runs (usually, the no-privileges user nobody),  so passwords are not stored in clear text.

Besides the httpd password file, the ncSA servers also respect  a group file in which you can define groups of users. Groups can  be treated like individual users with respect to access control,  so the group file can add capabilities and save data-entry time.  For the most part, syntax of the ncSA httpd group file is exactly  the same as that shown earlier in this article for the CERN/W3  group file.

There is one significant difference in what the two group files  may contain, however. As noted above, the CERN/W33 group file  can include group entries which consist of other groups. The ncSA  group file can include only individual users as members of groups.  Thus, the recursive staff group, consisting of all the members  of the personnel and management groups, is not possible in ncSA.  To create such a group, you would need to re-enter each user's  name in the group entry for staff.

Now that you've set up your password and group files, you're ready  to add username/password authentication in your GACF or LACFs.  Take a look at an example:

# Anybody in the personnel group can  get to the top level  # of the personnel filetree  <Directory /usr/local/web-docs/personnel>  AuthType Basic  AuthName Personnel Only  AuthUserFile /usr/local/etc/httpd/userpw  AuthGroupFile /usr/local/etc/httpd/ourgroup  <Limit GET>  Require group personnel  </Limit>  </Directory>

Here, in the GACF file, you've limited access to the top level  of the personnel tree of  the Web server. Only members of the predefined group personnel (defined in the ourgroup file) are allowed to GET (access) files in the directory tree, and they must provide a  valid username and password, verifiable against the encrypted  password in the userpw file.

Most of the lines in the example are clear, but a couple need  a little more explanation. AuthName is just an arbitrary label for your rule; you should put something  there that'll make sense when you read the rule a year from now,  and you can use a phrase here. The <Limit  GET> subsection of the file is the critical section,  in which you actually specify who has access. You can also include  comments in the file, as indicated by the first two lines, where  the # symbol is used.

As I've noted, you can use LACFs to refine the access rules in  your GACF. Here's an example of an ncSA httpd LACF: a file named .htacces in the personnel/executive subdirectory. See if you can translate its meaning:

AuthType Basic  AuthName Anne Only  AuthUserFile /usr/local/etc/httpd/userpw  AuthGroupFile /usr/local/etc/httpd/ourgroup  <Limit GET>  Require user anne  </Limit>

You're right; this rule limits access to the executive subdirectory to a single user: anne.  The heart of this rule is the matter between the <Limit> and </Limit> tags near  the end of the file. Other users, including the other members  of the personnel group, are  denied access, even if they give a correct password for themselves.  A dialog box will demand Anne's username and password. Notice  that this LACF file, which controls access to a single directory  (personnel/executive), does  not require the opening and closing <Directory> and </Directory> tags  required in the server's GACF because there are no subdirectories  in this directory.

Important Warnings About Username/Password Authentication

Unless the access rules change (that is, new LACFs are encountered)  as a user moves around on your intranet Web pages (as with the personnel/executive subdirectory  in the previous example), he will be prompted only once in his  browser session for a username and password. As long as he continues  his browser session, he can access all of the files and directories  available to him under the most recent access rule-without being  prompted again for his password. This is for the sake of convenience;  customers shouldn't have to repeatedly provide their usernames  and passwords at each step of the way when the access rule hasn't  changed.

However, this situation has important ramifications if you follow  it logically. Suppose Anne, having authenticated herself to access  the executive subdirectory,  leaves her Netscape or Mosaic session running, as most of us do.  Her privileged access remains open to all the files protected  by that one-time, possibly days-old, authentication. If she leaves  her workstation, pc, or terminal unattended when she goes to lunch  or goes home for the day, without any sort of active screen or  office door lock, anyone can sit down and browse the files and  directories that are supposed to be limited to Anne's eyes only.  This is a potential security breach, and one that the Webmaster can do little about. This is really no different from a user  who leaves his workstation unattended without logging off. Although  you can try to educate your customers about such everyday security  matters, even though they have very little to do with your intranet,  you'll agree a security breach like this can be potentially harmful  to all your work.

User passwords are transmitted over your network by most Web browsers  in a relatively insecure fashion. It is not terribly difficult  for a user with a network snooper running to pick out the httpd  network packets containing user passwords. Although the passwords  are not transmitted in clear text, the encoding/encryption method  is a very old and widely used one. Every UNIX system, for example,  has a program (uudecode)  that can decode the encrypted password in a captured httpd packet.  If you believe this may be a problem on your intranet, you'll  want to consider the secure Web servers and browsers that encrypt  user-transmitted data, as discussed in the article titled "Secure/Encrypted  Transactions".

About the Author:

No further information.




Comments

No comment yet. Be the first to post a comment.