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.
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:
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.
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.
comments powered by