Password Verification in AIX Version 4
AIX Version 4 introduces new and expanded tools for
access. It allows system adminstrators to write their
verification functions and to extend the system login
procedure to call
those new functions for user password verification.
It lets system
administrators specify allowed and denied login times,
ports for each user and permits an account to be locked
after a certain
number of failed login attempts. Ports can be monitored
accounts: a port may be locked for a specified time
period after a
failed login attempt and may be shut down completely
after exceeding a
threshold of failed login attempts in a given interval.
A locked port
can be enabled automatically after being unused for
some time. These
features prevent a password cracking program from probing
userids on the same port.
With Version 4, password history becomes available.
The system prevents
reuse of passwords within a given time frame and/or
within a cycle of
passwords. For example, a password cannot be reused
if it is in a list
of recently used passwords. The size of the list is
dictionaries can be specified to check new passwords.
This article explores the login configuration and user
features introduced in Version 4, then explains how
to write and
implement system password verification functions.
The login process references the files /etc/passwd,
/etc/security/passwd, /etc/security/login.cfg, and /etc/security/user.
/etc/passwd is the standard UNIX password file, owned
by root and world
readable. The layout and weakness of the original UNIX
have been explained elsewhere [Che94a, Fie88a, Fox85a,
As a remedy, AIX uses the shadow password file /etc/security/passwd
(Figure 1), which is owned by root and read/writable
by root only.
As shown in Figure 1, the second field in /etc/passwd
either contains an
exclamation mark or is empty, in which case the user
has no password.
The userid is used as a key to search for attributes
/etc/security/passwd. The password attribute refers
to the encoded
password, while lastupdate is the time in epoch (seconds
1 January 1970) when the password was last changed.
additional information on password changing and checking
The file /etc/security/login.cfg changed considerably
from AIX Version
3. It is divided into three parts: port configuration,
verification rules, and user definition. The default
stanza applies to
all ports. Each port can be defined separately and can
values in the default stanza entry.
Figure 2 shows an example of the Version 4 /etc/security/login.cfg.
Since most of the attributes are new with this version,
I will list each
and identify its function.
herald -- Message printed when port is opened by getty.
logindelay -- Delay in seconds between unsuccessful
logindisable -- Number of unsuccessful login attempts
before port is closed.
logininterval -- Number of seconds in which logindisable-specified
unsuccessful login attempts have to occur before port
loginreenable -- Minutes to pass before a locked port
logintimes -- Date and time logins on this port are
allowed or denied.
The format is
[ "!" ] : time "-" time
[ "!" ] day [ "-" day ] [ ":" time "-" time ]
[ "!" ] date [ "-" date ] [ ":" time "-" time ]
day is a digit between 0 and 6 representing the day
of the week,
starting with 0 (Sunday). date and time are both four-digit
the form mmdd and hhmm. Leading zeros are mandatory.
0001-0231 indicates 1 January until 31 March. month
ranges from 0 for
January to 11 for December. dd may be zero, so 0800
stands for the first
or last day in September, depending if it appears in
a start or end
context. For example, 0700-1000 indicates the first
day of August to the
last day of November.
time is a 24-hour clock always preceded by a colon.
Entries without a
leading exclamation mark allow access during that time;
exclamation mark denies access. Several values may be
delimited by commas. The sample entry in Figure 2 allows
Monday to Friday 7am till 7pm, 8am till 2pm on Saturdays,
and no login
logintimeout -- Timeout in seconds for user to enter
maxlogins -- Number of simultaneous logins per user.
This includes su and
and telnet sessions.
shells -- List of valid command shells.
Again looking at Figure 2, the second section is used
if you call an
alternate login program. The third section has only
one stanza; that
stanza applies to all users and must be named usw. The
/etc/security/user (see Figure 3) contains an entry
for each user, and
the default stanza applies to all users. Password rules,
password dictionaries, and password extension rules
can be specified on
a per-user basis. There are many more options, such
as setting a user's
initial umask and remote login permission (see [IBM94a]
for a complete
The attributes displayed in Figure 3 are:
ttys -- List of valid terminals to login.
auth1 -- Primary authorization method. Values are SYSTEM
password verification; NONE for no checking; and token;name
alternate login program. token is the key when searching
in the second
part of /etc/security/login.cfg. name is the userid
auth2 -- Secondary authorization method. Same values
as for auth1.
SYSTEM -- Describes the login requirements, which may
consist of multiple
or alternate methods. Values are NONE for no password
for local authentication only; compat for local and
System (NIS) authentication.
logintimes -- Login times for this user. Same syntax
pwdwarntime -- Number of days a warning message indicates
pwdchecks -- Defines a local password verification program
(see Listing 1).
dictionlist -- Filename of password dictionary used
checking. The file contains one word per line. If the
new password is
found in this file, it is rejected.
loginretries -- Number of failed logins before an account
histexpire -- Time in weeks before a password can be
histsize -- Number of previous passwords a user cannot
minalpha -- Minimum number of alphabetic characters
minother -- Minimum number of non-alphabetic characters
mindiff -- Minimum number of characters the old and
new passwords must differ.
maxrepeats -- Maximum number of times a character can
occur in a password.
minlen -- Minimum length of passwords.
maxage -- Maximum number of weeks for a password to
mixage -- Minimum number of weeks before a password
can be changed.
The default configuration in Figure 3 requires a user
to change the
password every eight weeks. The password must contain
at least one
alphabetic and one non-alphabetic character and each
character can be
repeated once. New passwords are checked against the
/usr/local2/adm/pwddictionary and verified using a locally
loadable module in /usr/local2/adm/checkpwd. Passwords
cannot be reused
within a year, and each new password must differ from
the previous 25.
Three days before a password expires, the user is reminded
on. Logins on Sundays are disabled.
Password history is enabled; the encoded password, with
the time it was
changed and the userid it belonged to, is stored in
/etc/security/pwdhist.dir. Root owns this file, and
it is read/writable
by root only.
The files /etc/security/lastlog and /etc/security/failedlogin
login attempts per user. The record includes time and
userid, remote host, and number of unsuccessful attempts
since the last
successful login (see [Ric95a] for a detailed description
of AIX Version
3 login configuration and tools to automate login surveillance).
number of unsuccessful login attempts exceeds the loginretries
the account is logged and a warning message is issued
when the user
tries to login.
/etc/security/portlog contains for each port the time
a failed login
occurred and the time a port was locked. Both are reset
when the port is
reenabled. The unsuccessful login times and occurrences
against the values of logininterval and logindisable
whether a port should be locked.
Extending Password Verification
As I noted earlier, you can write your own extension
to AIX Version 4's
password verification functions. Extending the password
requires you to write a C program, such as checkpwd.c
(Listing 1) and to
create a dynamically loadable object file [Cha95a].
Use the -e checkpwd
option when you compile the sample code. This causes
the compiler to use
checkpwd() as the entry point instead of main().
You can use any function name other than main(). The
login process uses
the "load system" call to load the files listed
in the pwdchecks
attribute. The system call returns the address of the
with the -e option, and that function is then called.
return value indicates success (zero) or failure (nonzero).
the returned error message must be allocated from the
heap; the login
process will free it.
Writing your own password extension requires some care,
and most important, the loadable file must be placed
in a secure
directory with permissions allowing only root to access
it. No ordinary
user must be allowed to replace this file. The code
is executed as part
of the login process, with root's environment, credentials,
limits; for this reason, you should avoid creating child
create/open files. Don't call exit: this would terminate
the login, su,
and passwd programs, so that a user might not be able
to login at all.
If you change signal handlers, reset them to their original
before your function returns. Some of the handlers are
used by the
calling process as well.
Alternate and Additional Login Checks
AIX Version 4 lets you replace or augment the login
Additional programs must be defined in the second part
/etc/security/login.cfg as trusted login programs. Figure
4 lists as the
key mylogin and refers to an executable /usr/local2/adm/mylogin.
program may be called instead of, before, or after the
password prompt, depending on the sequence in attribute
In the login in Figure 4, the attribute auth1 would
/usr/local2/adm/mylogin, with "richter" as
its only parameter. It is
this program's responsibility to ensure the user's identity.
a password, one can think of a fingerprint or voice-checking
exit value of 0 indicates success; any other value,
failure. No other
authentication program is invoked, since the value of
SYSTEM was set to
NONE. On the other hand,
SYSTEM = "files"
auth1 = SYSTEM,mylogin;richter
calls the standard login procedure before the local
Auth1 = mylogin;richter,SYSTEM
reverses the sequence. If both indicate success, access
When you write your own login program, the same warnings
apply as for
extending the password verification. However, no special
flags are required.
Figure 5 (mylogin.c) shows a sample program used as
an alternative login
program. Function authenticate is used to verify the
Authenticate maintains state information and may be
called several times
to verify a user. A nonzero value of reenter indicates
functions must be called again. The first call to authenticate
the password prompt in parameter message. The second
call verifies the
user's response; parameter prompt contains the password
in clear text.
Password mismatches are indicated by a nonzero return
code, and an error
message is returned in parameter message. However, if
you set SYSTEM =
NONE, authenticate does not verify the user's password.
Che94a. Cheswick, William P. and Steven M. Bellovin.
Internet Security. Reading, MA: Addison Wesley, 1994.
Fie88a. Fiedler, David, and Bruce H. Hunter. UNIX System
Indianapolis, IN: Hayden Books, 1988.
Fox85a. Foxley, Eric. UNIX for Super-Users. Reading,
MA: Addison Wesley,
Ric95a. Richter, Thomas. "Login Surveillance on
AIX," Sys Admin, Jan/Feb
1995 (vol. 4, no. 1), pp. 21-32.
Woo85a. Wood, Patrick H., and Stephen G. Kochnan. UNIX
Indianapolis, IN: Hayden Books, 1985.
IBM94a. IBM. AIX Version 4 File Reference (IBM RISC
Cha95a. Chapman, Scott. "Extending password composition
rules in AIX
Version 4.1," AIXtra: IBM's Magazine for AIX Professionals, 1995
(vol. 4, no. 5), pp. 57-61.
About the Author
Thomas Richter studied mathematics and Computer Science
University of Ulm, Germany. He has worked on various
UNIX platforms as a
software developer using C/C++ as main programming languages.
projects include compiler construction, device drivers,
programming. He has also administered various UNIX machines
for the last
8 years. He has worked for IBM UK for 18 months. In
July 1994 he
returned to Germany where he works on device drivers
for devlopment. He
can be reached at firstname.lastname@example.org.