02-21-2012 04:54 AM
If a slack/careless administrator manages to set the root password to nothing/blank on an hpux 11.31 server is there a way to check this has happened? Even better would be a way to stop this happening (at the server level - though HP support have said this is not possible).
The /etc/shadow shows an encrypted password string for a blank password.
Solved! Go to Solution.
02-21-2012 07:21 AM
For a regular user, it would be possible to enforce a minimum password length; but for root, I think all such limitations only cause an extra warning to be displayed, but allow a short password to be set if root insists on it. This is because root has the ability to change or override all restrictions anyway: root could just as easily disable the length requirement, set the password to blank, then re-enable it.
Some login methods can be configured to disallow empty passwords on principle. SSH does so by default: unless /opt/ssh/etc/sshd_config includes an explicit "PermitEmptyPassword yes", all SSH login attempts with an empty password will be rejected, no matter what the user's password currently is.
It would certainly be possible to write a PAM module that disallows authentication if the password is blank. (For comparision, modern Linux PAM libraries behave this way by default, and require an explicit "nullok" option to allow logins with a null password to succeed.)
Checking for null root password is easy: attempt to login as root with a null password. If login is successful, you know the root password has been set to blank.
02-21-2012 12:05 PM
Actually, there is a very useful (but overlooked) utility for checking logins, and it is called logins. :-)
logins -p (show all user IDs with no password)
logins -d (show all duplicate user IDs)
It always returns zero so for scripting, you'll have to check for any output.
02-21-2012 04:08 PM - edited 02-22-2012 05:09 AM
I very much doubt "logins -p" performs a brute force attack to detect if an hashed password is a blank-equivalent. Most likely it just checks whether the password field in the appropriate file is empty or not.
(Edit: I tested with HP-UX 11.23 and 11.31 with shadow password support enabled. Even if you set a blank password with the "passwd" command, it will produce a hashed password string and thus it won't be detected by "logins -p". The "logins -p" will only list the users that have no password hash in the /etc/shadow file, just as I expected.)
But the original poster indicated this case won't benefit from a simple check like that:
> The /etc/shadow shows an encrypted password string for a blank password.
For example, if the system still uses the traditional crypt() for password hashes, all these (and more) hashes would be equivalent to just pressing Enter at the password prompt:
Tools like "logins -p" can only detect the non-existence of a password hash in the passwd/shadow file: detecting that an existing password hash is equivalent to a blank password is not implemented.
For example, if you use a separate program to generate a blank-equivalent password hash, and then install the already-encrypted hash with "usermod -p", you'll get a blank password that is not immediately detectable as one.
If you suspect that blank-equivalent or otherwise bad passwords are in use, "John the Ripper" is an useful tool for checking large numbers of password hashes quickly. See: http://www.openwall.com/john/
02-22-2012 02:21 AM
logins -p no use for the reason specified. Also, the PermitEmptyPassword=no is ignored when using PAM.
Running john down a number of passwd files of (usually) 'safe' passwords just chews cpu so it's going to have to be a login script as suggested.
Appreciate the assistance.