Improve AIX Security With Password Hashes

UNIX-based systems, such as AIX, store passwords for users using hashes. Let’s explore the basics of how password hashes work, how to improve the security of your password hashes, and how to change passwords directly with hashes.

Hash Basics

A hash is a cryptography term for a one-way function. The input to the hash algorithm is the clear-text password and the output is a encrypted string of characters. Hashes are “one way” because the encrypted string of characters can’t be directly decrypted. For example, if a user sets the password “colorado,” AIX will use the password hash algorithm to encrypt it to something like “wQzBDTnqVHbXo.” Because hashes are one way, it’s impossible to take the encrypted “wQzBDTnqVHbXo” and decrypt it back to “colorado.”

AIX stores the password hashes for each user in a stanza in the /etc/security/passwd file. For example, here’s the stanza for the user brian:

brian:
	password = wQzBDTnqVHbXo
	lastupdate = 1336926064

Each time the user logs into the system and types the password (colorado), AIX will compute the hash for the password the user specified. AIX will then compare this password hash with the one stored in /etc/security/passwd—if they match, the user will be allowed to login.

Brute Force

Password hashes are mathematically one-way functions, but it’s still possible to attempt to use “brute force.” This means trying every possible password, computing the password hash for it, and seeing if the result matches the user’s password hash.

Suppose an attacker has access to a user’s password hash in /etc/security/passwd and also knows that the user’s password is only one character long. It would be possible to write a program to compute the hash for the password “a,” “b,” “c,” “d,” etc., until the password hash generated matched the user’s. Once a match is found, the attacker would know the user's password. The longer the password, the more difficult using brute force becomes.

Some Salt With That?

Hash algorithms use a concept called “salt” to increase their security. When a user sets a password, AIX generates a bit of random data—the salt—to make the password hash even more extraordinary.

The main reason for salting is to prevent pre-computed dictionary attacks aimed at cracking the password hash. The brute forcing method is relatively slow, because for every possible password, the CPU must run the hash algorithm to see if there’s a match. To speed up password hash cracking, it’s possible to use a “rainbow table.” It’s simply a pre-computed list of passwords and their matching password hashes.

Because the rainbow table is pre-computed (usually on large clusters of computers with significant CPU power), it’s simply comparing the password hashes in the rainbow table with the password hash of the user. It’s extremely fast, because no password hashes need to be computed during this check.

Password hash salting mitigates rainbow tables by adding a bit of extra information to the password. In our example, the password “colorado” has a password hash of “wQzBDTnqVHbXo.” With the default AIX password hash crypt, the first two characters are the salt, ie., “wQ.” These two characters were randomly generated by AIX when the password hash was computed. The extra salt characters make it so pre-computed rainbow tables would have to include every possible salt value for every possible password, which greatly reduces their practicality and threat.

Also, without salting, if two users set their password to the same value, the hashes in /etc/security/passwd would be identical. With salting, even if two users have the same password, the salts, and therefore the encrypted passwords, will be different.

More About /etc/security/passwd

As mentioned previously, each user has a password hash stanza in /etc/security/passwd. Two special entries in this file have special meaning. The first is a password field set as nothing as in this example:

brian:
	password =
	lastupdate = 1336926064

This allows anyone to log in or “su” to the brian account without being prompted for a password at all which, in general, is a really bad idea.

The other special entry, which is more common, is having the password field set to an asterisk (*) as in this example:

brian:
	password = *
	lastupdate = 1336926064

Because the asterisk isn't a valid password hash, this effectively locks the password on the account. This makes it impossible to log in to this account using a password, however, if SSH keys or other authentication methods are available, other than passwords, the account might still be accessible.

Copying Password Hashes

It’s possible to take the password hash from /etc/security/passwd for a user on one server and copy it into the /etc/security/passwd file on another server. This can be helpful when creating a user account on a new server. By copying the password hash from the old server, the user can log into the new server with the same password from the old one. To do this, simply replace the user’s stanza on the new server in /etc/security/passwd with the stanza from the old one.

Password Hash Options

By default, AIX uses the crypt password-hashing algorithm. There are a couple of serious security implications of using this algorithm:

1. With the crypt algorithm, passwords are limited to eight characters. AIX will still be happy to let you think you’ve set a password that’s longer than eight characters, but when you login, it’s only looking at the first eight characters and ignoring everything else.
2. Another concern is the algorithm used by crypt is old and easy to compute, and the hash generated is short. This makes it faster and easier to brute force.

Modern AIX (the later version of 5.3 and beyond) now supports loadable password algorithms. This adds support for the MD5, SHA1, SHA256, SHA512, and Blowfish algorithms (listed in /etc/security/pwdalg.cfg).

These additional algorithms are much more secure than the default crypt algorithm. Each supports 255-character passwords, except Blowfish, which supports 72 characters. They also have a larger password salt than the default crypt algorithm, and are harder to brute force because it takes more CPU time to compute the hash compared to the crypt hash.

When you change the default password hash algorithm, it only takes effect for password changes that occur after that point. Existing password hashes will stay the same and continue to work, but will simply be updated to the new default hash algorithm the next time users change their passwords.

To change the password hash algorithm, you can use the following command syntax and specify one of the password algorithm options (in this example, SHA512):

chsec -f /etc/security/login.cfg -s usw -a pwd_algorithm=ssha512

If I change the password for the user brian to “colorado” again the /etc/security/passwd file will now show:

brian:
	password =
{ssha512}06$otYx2eSXx.OkEY4F$No5ZvSfhYuB1MSkBhhcKJIjS0.q// wdkcZwF9/TXi3EnL6Qero
nmS0jCc3P2aEV9WLi5arzN1YjVwkx8bng..
	lastupdate = 1336931598

As you can see, the SHA512 algorithm generates a much longer hash than the default crypt algorithm.

Changing Passwords Directly

System administrators commonly use the chpasswd command to easily change passwords through scripts. For example, if you’d like to change the root password, you could run the following command: echo "root:colorado" | chpasswd -c which would change the root password to “colorado.” The “-c” clears out the ADMCHG flag so the user isn’t prompted to change the password at next login.

The problem with using chpasswd in this manner is the clear text password is visible on the screen and also in shell history files. If chpasswd is run from a script, the clear text password would be visible in the script.

A better way is to use the -e flag with the chpasswd command, which specifies you are providing a password hash rather than a clear text password. You can generate the default AIX crypt password hash for any given password by typing:

openssl passwd

Openssl will prompt for the password twice and then display the password hash:

# openssl passwd
Password:
Verifying - Password:
Ywa7SDcDhSnHA

You can then run echo “root:Ywa7SDcDhSnHA” | chpasswd -ec . With this method, even if someone gets access to your shell history files, your scripts, or is watching your screen, they won’t see the clear text password.

Hashed Out

Password hashes are important to understand because they’re one of the main ways users are provided access on AIX systems. Understanding how they work will allow you to better administrate AIX servers.