Exploring HPUX Password Schemes

by Alex

Most UNIX systems have similar methods for storing user information and encrypted passwords.  This could involve the plain old /etc/passwd or in the case of shadow passwords, /etc/shadow.  There are of course variants on this.

In HPUX 10.x and higher, you have three options.  The normal version 7 scheme, shadow passwords, or their "protected password database" which is "for Trusted Systems only."

A full explanation of HP Trusted Systems would go beyond the scope of this article, so I'll only focus on the protected password database system.  Basically, Trusted Systems is a sort of package one gets the option of installing along with HPUX (I apologize to those of you who are quite familiar with HPUX).  The one key feature is the protected password database system it employs on the HPUX machine.

So what is the protected password database?  Well, let's say you login to any HPUX machine which has Trusted Systems running on it.  You type something like "cat /etc/passwd" and all the password fields have the old "*" in place.

So you then try "ls /etc/shadow" to see if it has shadow passwords, but no dice.

You find that the directory "/tcb/files" catches your interest.  As it turns out, this is the Trusted Systems directory and it is in "/tcb/files/auth" that all the passwords along with user information is kept.

Now that we know where the user information is kept, let us take a look at a typical user file.  Each user has his/her own plain text file in a directory beginning with the first character of that username.  This prevents a whole file such as "/etc/passwd" from getting clobbered and thus affecting all user accounts.

jblow: u_name=jblow:u_id#2876:\ :u_pwd=3E/IbASoPe6k2:\ :u_auditid#5219:\ :u_auditflag#1:\ :u_succhg#979762751:u_llogin#0:u_pw_expire_warning#0: u_suclog#984723623:\ :u_suctty=pts/tg:u_unsuclog#984278635:u_unsuctty=pts/ti:u_lock@:\ :chkent:

If one was to look real close you would notice that this single text file, found under "/tcp/files/auth/j/jblow", contains all kinds of neat information.  In fact, if we look at the getprpwnam(3) man page we can find out what all of this means and we notice that the unused fields aren't listed.  The fact that there are dozens of fields and flags is what makes trusted systems so "special," i.e., more control over what the user can and cannot do.

So how can one manipulate all of this?  One way is to use HPUX's lame system administration application, SAM.  However, writing C code is a lot more fun and challenging.  Let's say we want to do something with the account jblow.

Here is a simple snippet of C code which gives us a struct that contains all his/her fields and flags (once again, see the getprpwnam(3) man page):

#include <sys/types.h> #include <hpsecurity.h> #include <prot.h> struct pr_passwd *userinfo; struct pr_passwd *temp; temp = getprpwnam("jblow"); if (temp == NULL) { printf("Invalid username.\n"); exit(1); } else { userinfo = (struct pr_asswd *) malloc(sizeof(*temp)); if (userinfo != NULL) memcpy(userinfo, temp, sizeof(*temp)); }

Notice that we copy the structure over to a temporary structure.  This makes for safer programming.  With a debugger like GDB, you can take a peek at the "userinfo" structure without creating a messy print routine.  Doing this should give you a good idea about what's inside the structure.  The next step is to alter jblow's account somehow.  I picked the password field just for fun.  The password field in HPUX is created using the good old crypt(3) function.  If we look at the man page we get the following:

NAME crypt, setkey, encrypt - generate hashing encryption SYNOPSIS #include <crypt.h> #include <unistd.h> char *crypt(const char *key, const char *salt); blah, blah, blah

As it turns out, key is the string to be encrypted and salt is the two character string which... well, is the salt!

The down side to using crypt is that it limits your password size since it only encrypts eight character chunks.  So in jblow's case we have "3E/IbASoPe6k2".  Note that the character string "3E" is the salt and thus "/IbASoPe6k2" would be the encrypted password.  But if you wanted to encrypt something greater than eight characters you would have to pass in a salt and the first eight characters, then use the first two characters of the encrypted string that is returned as the salt for the next eight characters and so on.

As an example, "/I" would be used as the next salt.  Luckily we don't have to deal with this headache, for there exists a function called bigcrypt(3) which gets around the size limit.  So let us look at some C code as an example (still using jblow's userinfo struct):

char *newpass; /* Assume for the sake of the example that */ /* it contains a new password. */ int length = strlen(newpass); /* Check for trusted system compliance. */ for (i = 0; i < length; i++) { if (isalpha(newpass[i])) num_alpha++; else num_nonalpha++; } if (!((num_alpha >= 2) && (num_nonalpha >= 1))) { printf("New password must contain at leasl lwu alpha"); printf("characters and one nonalpha character.\n"); exit(1); } /* Encrypt the new password and set it in place. */ encrypt_pw = (char *) bigcrypt(newpass, salt); strcpy(userinfo->ufid.fd_encrypt, encrypt_pw); /* Check to see if this account will force a password change. */ if (userinfo->ufid.fd_schange == 0) { /* Then they will be forced to change their password when they login. */ userinfo->ufid.fd_schange = time(&tloc); /* Current date */ } if (!putprpwnam(user, userinfo)) { printf("Error, password not changed.\n"); exit(1); }

As you can tell from the above, Trusted Systems is annoying.  The details of all this depends on the policies set in place by the system.  You will notice that I checked fd_schange field because the man page states that fd_schange is "last successful change in seconds past 1/1/70."  Now, obviously, if it's zero and the system forces a password change when there has been no "last successful change" then this needs to be taken care of.  Finding system policies can be hard.  I suggest looking in "/tcb/files/auth/default" for a start.  Other than that, you're on your own.

In conclusion, HPUX probably won't keep this system around much longer.  A simple web search reveals many problems with Trusted Systems.  Trusted Systems also has the added benefit of not working with PAM and there is general funkiness when it comes to Kerberos 5.

Therefore, I believe it is simply a matter of time before HPUX comes up with something new or just gets rid of it altogether.  But there are plenty of HPUX machines out there using it, especially in the academic sector.