Pp. 67-76 of the Proceedings

Abstract

There are a plethora of password changing programs available for users and systems administrators to use. Most of the existing password changers, however, fall short in some way. Either they are still text based, requiring users to use unfamiliar tools in unfamiliar environments, or they are part of an all encompassing framework - designed to completely supplant the entire existing account creation, maintenance and distribution process. Our program is designed, first, to be usable without training or human support. Second, it is designed to use existing distribution databases such as NIS and LDAP. We integrate many of the features of prior password changers such as the Cracklib library, character classes, and rules for password selection. We try to provide easy extensibility both in terms of database support and by providing other user-focussed programs that use the same authentication framework.

Introduction

Auburn University College of Engineering has two primary platforms for supporting a broad clientele. These are Windows boxes which use SMB [1] for file service, and UNIX boxes which use NFS for file service. In order to use any network services, a user must be authenticated. For the UNIX side, this means NIS, NIS+, or LDAP.

To provide authentication to NT boxes we use Samba [2]. To do this semi-securely [3] requires a separate encrypted password database. In their respective, encrypted formats, the UNIX password and the Microsoft password are incompatible, irreversible one way hashes; there is no method to generate one from the other. This means neither system's builtin password changing mechanisms can be used. This irreversibility problem can be applied by extension to other one way password formats such as BSD44, Apple formats (e.g., CAP [4]) and several Linux formats.

Early in 1999 we decided that we should replace the existing - functional but archaic - text-based password changer with a Web-based mechanism. The old system required users to login to a UNIX machine to change their passwords. Many of our new users had no experience with applications like telnet, ssh, or even UNIX. Text based solutions requiring login to an unfamiliar environment were difficult to support. A Web design allowed greater platform availability and improved usability over our previous system. We also had an opportunity to revise the entire password changing system and integrate other services such as email forwarding.

We wrote our code primarily in PHP [5]. Some functions required a PHP loadable module written in C. One helper program was written in Perl.

Prior Art

A lot of work has been put into account management systems over the years. Many USENIX, LISA, and even ;login: articles have been written concerning these works. Nearly all of them have a systems administrator focus, which is natural when one considers that systems administrators are always trying to make their jobs easier. However, the works tend to focus on systems administrator specific tasks such as creating, adding, deleting, and ongoing maintenance of accounts. When usability was addressed, it was usually most evident from a systems administrator's point of view: make less work; provide more scalability.

Auburn University College of Engineering (hereafter referred to as AUCOE) already had account maintenance tools in place with no obvious need for wholesale replacement. We required an intuitive user interface - to allow users to be able to do simple tasks on their accounts without any sort of training - and minimal support.

The main differences between the AUCOE framework and prior implementations are:

• It integrates prior work and tools such as Cracklib [6], character classes, etcetera. (some, but not all, of the others also do this.)
• It provides easy extensibility to other formats such as LDAP and custom databases.
• It is much simpler in scope than the others. Some of them are enormous and handle everything from account creation to interfacing with a human resources database. The AUCOE changer provides a means for users to easily change their passwords.
• Our main focus is user usability vs. administrator usability.
• The incremental approach builds on top of existing frameworks such as NIS, NIS+, Samba, and flat files, rather than replacing them.
• Decoupling password choosing from distribution and propagation allows us to not have to worry as much about locking and conflict resolution.

The author was not able to gather meaningful data - because of age and lack of access to the original papers - on these password and account management systems: Maryland [7], ACMAINT [8], Apollo [9]. References are provided at the end for those having hardcopy proceedings.

Many of the features of the following command-line, pro-active password checkers have been integrated into our password changer: npasswd [10], passwd+ [11], ANLpasswd [12], Epasswd [13]. The password vetting routines from these programs tend to be tightly coupled with an existing command-line interface and propagation mechanism. Rather than extracting the proactive changing logic and rules from any of these programs, it was easier for us to use Cracklib and construct the various password rules and classes in native PHP.

Information about current availability of and updates to other user account management systems was difficult to collect. Some of the systems listed may have had updates more recent than the author was aware. Some of them were designed to manage access control where certain users are only authorized to use certain machines, or the home directory may differ based upon the machine. All of them had, as a primary focus, the goals of modernizing and automating the maintenance of user accounts at a site; password changing, password synchronization, and usability, if mentioned at all, were typically secondary. The most currently relevant systems are compared in Table 1 based upon the following criteria:

• Design philosophy
• Custom database vs. existing database (e.g., NIS, LDAP)
• Distribution and synchronization methods for accounts and passwords
• Extensibility - perceived degree of difficulty of adding a new output format, heterogeneous machines, configuration intricacies, etc.
• User interface focus
• Language(s) written using and/or configured with
• Release status (may be out of date)
• Other characteristics that may be of interest

Genesis

The framework used by the AUCOE password changing system came into being ad hoc. The project that originated the framework provided a means by which users could forward their email. The previous forwarding program was text-based and required users to login to a UNIX machine to run it. The number of users wishing to forward their email was growing. The time spent supporting these non-UNIX users was growing proportionately.

We desired to avoid CGI and its inherent security difficulties and call-out overhead. After a short period of investigation, comparing the tradeoffs of mod_perl [19] versus learning PHP, a new language, the author chose PHP. PHP combined C and Perl syntax without the special variable cruft. PHP had support for persistent file handles. Finally, PHP appeared to be easier for non-experts to learn and use quickly.

In keeping with the tenets of user-interface design, the password change form was designed to be simple but usable. User feedback was incorporated to make the form what it is today (Figure 1). The results were positive both in terms of user satisfaction and reduced support by administrative staff. We were encouraged to try again: with passwords.

Design Goals

Our system for changing passwords was designed to meet certain goals:

• It must have universal accessibility.
• It must be secure.
• It must be easy for novices to use.
• It must not rely upon extensive online help.
• It should have access to online help for users having trouble.
• It must not inhibit expert users.
• It must be scalable.
• It must provide clear and meaningful, jargon-free responses.
• It should build upon existing distribution and synchronization mechanisms: NIS, NIS+, Samba, LDAP.
• It should be easy to extend as other distribution and synchronization mechanisms become available.
• It should borrow techniques from prior password changing implementations.

It Must Have Universal Accessibility

In other words, use the Web. It is time consuming to develop clients for various architectures. The flexibility and speed of dedicated, platform-dependent password clients was not indicated.

It Must Be Secure

Because users are providing information that gives access to their accounts, and because secure, local access cannot be assumed (though it could be enforced), it is imperative that no information be transmitted over the network in the clear. There are multiple paths of transmission involved. See the Security section for more details.

The Web server must verify the username and old password for authenticity. Our implementation provides multiple ways to do this.

• Make the Web server a NIS slave.
  PHP can directly access DBM files, so verifying passwords by giving the Web user account read-access to the encrypted password database is possible. (Before anybody gets apoplectic, please continue reading.) If your Web server is single-purpose, contains no extra CGI, no other user scripts, and no unknown functionality, this is relatively safe.
• Use the provided pwcheck daemon.
  The pwcheck daemon uses a secure algorithm to verify the username and password. If neither is correct, a non-specific negative result is returned: users are informed that either their username or password is incorrect.
• Use another authentication mechanism.
  While not provided, it would be fairly easy to interface with LDAP, NIS+, or another authentication database to verify a user's identify. One of the difficulties of this approach is choosing between the lesser of two evils. Do you wish to give your Web user root access to the entire authentication database or do you wish to provide a setuid root helper program that becomes the user prior to checking the encrypted password? This is the primary reason why the pwcheck mechanism is provided. It is discussed in more detail in the Security section.

  It Must:

  Be Easy For Novices To Use
  Rely Upon Extensive Online Help, and
  Provide Access To Online Help For Users Having Trouble

  These three goals are complementary, and might even be merged into one. The distinctions among ease of use, having online help, and relying upon online help, though subtle, are important. The interface must be intuitive. One of the well-known facts of user-interface design is that users rarely, if ever, read any online help before attempting to do something. They usually dive in oblivious to the circling sharks. The interface must be intuitive.

  If a user cannot sit down and use a password changing program without training or referring to a manual, the program should be re-evaluated. We have gone through several iterations of user feedback and modification. There is, however, a difference between using the program without requiring a manual and referring to supplemental help should the password choice be insufficient. We avoid the requirement to read online help before-hand by providing abbreviated rules for choosing a password right at the top of the Web form. The rules (Figure 2) are specific enough to be easily understood, but small enough to fit entirely on the form and in the browser window.

  ---

  
  Figure 2: Password verification and update flowchart.
  
  

  ---

  After each rejection of a password based upon the given rules, the user is given the opportunity to follow a link which gives suggestions for and examples of choosing a password. Failure messages are communicated in bold red letters in a larger font and written at the top of the page as the form is redrawn, giving clear visual feedback about problems.

  It Must Not Inhibit Experts

  By providing a short set of rules, but not overwhelming the user with extensive directions, the interface is usable by experts.

  It Must Be Scalable

  Most of the scalability (and locking) issues are pushed back to the distribution mechanism and thus avoided. The interface must still, however, be able to handle the case where a number of users connect simultaneously. The worst case scenario can probably be attributed to university environments when new accounts are generated at the beginning of each term. Even in this scenario, however, it is extremely unlikely for more than a few users to change their passwords at a given time. Many of our users opt to keep the random FIPS-181 [20] style passwords that they are issued. Even if there was a Freshman computer lab where the instructor dictated that all students must change their passwords, changes would still not be simultaneous. People read, type, and think about their passwords at different rates. The worst case would probably not be more than 5 to 10 simultaneous password changes, which is easily achieved even with a modest PC as the Web server. In practice, even in its 18 months of existence, it has been unusual to have more than one person trying to change a password in any given five minute interval.

  Locking issues, similarly, are not a great concern. Most of the methods to change passwords in the existing back-end databases are already serialized. NIS, NIS+, and LDAP already have their own locking mechanisms. Even when we update our Samba password file with the encrypted MD5 hashes, we use a simple, Perl, single-threaded daemon to handle network requests from the Web server and update the flat Samba password file. (See the Extensibility section).

  It Must Provide Clear and Meaningful, Jargon-free Feedback

  User feedback issues have been partially previously addressed. At the risk of appearing to climb onto a soapbox, this is an area that is ignored far too often by systems administrators developing user interfaces for users. Users do not care - and should not be burdened - with messages about errors in some anonymous line of computer code. We systems administrators, as a community, are particularly guilty of these transgressions. The AUCOE program gives messages in plain English such as `New passwords do not match. Please retype them.' , or `Passwords require at least six characters', or `The new password you entered is too similar to your full name or username.' Upon successful completion, the program explicitly tells the user: `Your password has been changed successfully and will be ready for you to use anywhere in engineering in the next 10 minutes.', giving them explicit expectations and scope.

  It Should Build Upon Existing Distribution And Synchronization Mechanisms

  One of the drawbacks - or features, depending upon your point of view - with some of the other systems is that they require wholesale replacement of existing mechanisms. This means modifying every machine, or replacing the entire account generation mechanism, or tailoring lots of configuration files. Sites starting with nothing, sites having special access requirements, or sites mired in complicated legacy scripts may have no qualms about replacing an existing system. We provide an incremental approach to sites that, like us, already have established account generation and maintenance mechanisms. It is not always possible to build incrementally, but in our case it was desirable.

  It Should Be Easy To Extend as Other Distribution and Synchronization Mechanisms Become Available.

  PHP, like Perl, is a "kitchen sink" language. It contains builtin interfaces to many databases and a rich set of string processing and system interface functions. It also has a well-documented and easy to use C API for extension. The Cracklib module is written as a loadable extension, as are methods for generating Samba hashes, and calling NIS for password update. TCP/IP sockets and cryptographic functions are also builtin providing yet another means for extension: client/server communication.

  Architecture and Implementation

  The code, where possible, was written in PHP for Apache [21]. A dynamically loadable PHP module was constructed as an enhancement. We also created a Perl helper daemon on the Samba PDC to accept network connections from the secure Web server and update the Samba password file.

  Figure 2 shows a high-level flowchart of a password change transaction. The `auth method' box encapsulates all of the functionality for checking to see that the username and old password are valid, as well as running the rule checks and Cracklib on the new password. Upon successful validation, the respective authentication databases are updated and status is returned to the user. The dashed "valid auth" line is conditional upon success of the authentication method. The dashed "update" line to the other box represents generic extensibility.

  Configuration is currently managed through a PHP include file: globals.php3. Figure 3 shows a sample, commented globals.php3. This file lets you define and configure your authentication services so that when a user changes a password, the appropriate databases are updated.

  ---

  // Who do you want administrative mail (errors, etc) send to?
  $Admin_Staff = "admin";
  // General Vars - length of passwords
  $MAXlength = 8;
  $MINlength = 6;
  // Error logging (daemon|error) (consult syslog.h)
  $SYSLEVEL = 27;
  // comment this out if you don't have NIS.. If you do this, you
  // better have LDAP (or skills to modify passwd.php3)
  // Note - this is for submitting the password change.
  $have_NIS = 1;
  $NIS_domain = "eng.auburn.edu";
  // This is for checking the current password
  // For machines with direct access to shadow password file,
  // set $direct_access = 1; and set password file like the following
  // line:
  // $pw_dbm = "/var/yp/domainname/passwd.adjunct.byname";
  $direct_access = 0;
  // Where do you keep your user .forward files?
  $forward_path = "/forwards";
  // If you use the forward function, choose the location of your php_file
  // helper auxiliary program
  $php_forward_helper = "/etc/local/php_file";
  // For getting page count database info. Basically, nobody really
  // cares about this but us (Auburn). It's used in paper.php3.
  $getpages = "/etc/local/getpages";
  // Change these for LDAP
  // ldap_uid should be an account with create and modify privileges on
  // everything in your Samba and NIS ldap trees.
  $have_ldap = 1;
  $ldap_server = "ldap.your.domain";
  $ldap_uid = "root";
  $ldap_pw = "rootpw";
  $ldap_smbdn = "ou=people,dc=eng,dc=auburn,dc=edu";      // Samba tree
  $ldap_nisdn = "ou=people,dc=eng,dc=auburn,dc=edu";      // NIS/UNIX tree
  // For socket based manual updates to an smbpasswd file, this is
  // the host. Uncomment it here and change it as appropriate
  // $SMBHOST = "smbhostname";
  

  
  Figure 3: PHP configuration file.
  
  

  ---

  The provided PHP loadable module is written in C. There are four main functions in this module. The checkpass function is used to verify the username and password as accepted from the user's browser. It calls pwcheckd on the server as detailed in the Security section. The crack function calls the Cracklib library with the user's desired new password. The passwd function calls the RPC yppasswd function to change the user's password in the NIS password map; the NIS master is set at compile time in the Makefile. Lastly, the smbpasswd function takes the user's plain text password, creates the NT hash pair, and returns the ASCII representation to PHP for transmission to the smbdaemon program. Transmission is accomplished with standard sockets.

  Smbdaemon is a simple Perl program running on the Samba PDC machine. It is a 130 line Perl program at this writing. It listens on a well known port for updates, and then writes them to the private Samba smbpasswd file.

  Security

  There are five major areas where security needs to be addresses:

  • On the Web server machine.
  • Between the Web browser and the Web server.
  • Between the Web server and the pwcheckd daemon (if used).
  • Between the Web server and the authentication database (during updates).
  • In ancillary programs.

  On The Web Server Machine

  Changing passwords has broad security implications. We strongly recommend that you dedicate a machine to these 'user services'. Do not install this software on your general Web server. Do not give users interactive accounts on the machine itself. Users given direct access to the machine may have access to files that they should not.

  Browser to Server

  As discussed in the goals section, the transactions between the client browser and the Web server must be encrypted using HTTPS, preferably using 128 bit clients. You should force your Web server to only accept high grade security connections.

  If you decide to setup the Web server as a NIS client, you will authenticate users by directly comparing their encrypted passwords in the shadow password file with their passwords passed from the browser. In this case, you do not need to worry about passing the user's password over the network (because the files are local - except of course during periodic NIS synchronization updates). You do, however, need to be doubly certain that you do not give any users shell access to the machine. Additionally, you should setup NIS to use shadow passwords.