Every day I ssh in to 3 or 4 independent Unix accounts. I have been regarding them as more or less "equivalently secure" on the grounds that I'm using ssh, but after learning of how much variety there is out there in password-hashing schemes and their resistance against dictionary attacks I've become a lot more interested in learning the specific details for the systems I use.

I have found some too-brief summaries of what some OSs use by default (e.g., see here), but I'd like something more detailed. More importantly, I'm less interested in what various OSs do "out-of-the-box" than in what the specific systems I log in to do. Is there a standard way to find this information?

(I hope this question is not too naive. Yes, of course, a password cracker would also like to know the information I'm asking about, but my understanding is that no competently designed password-handling scheme hinges on its being secret. Therefore, I expect that the information I'm after should be readily available to the users of a system.)

  • As long as the systems use MD5 based hashing or anything stronger, you can protect yourself by using strong passwords. A password with 128 bits of entropy hashed with MD5 will most likely remain secure for many years to come. If you have any influence on what hashing is used, I wouldn't recommend MD5, something based on SHA2 would be safer. – kasperd Jan 3 '15 at 23:09
  • If you use ssh keys, the system's password hashing will not be used - only your key will be used. – Martin Schröder Jan 4 '15 at 3:09
  • 1
    @MartinSchröder That's true. But as long as the server permits logins using password, weaknesses in the hashed password could still be exploited. However if you do use an ssh key and never use the password, then there are no drawbacks from choosing a very strong password. – kasperd Jan 4 '15 at 13:33

Short version:

  1. /etc/shadow contents will tell you what format each user uses, but needs root to see them - @MikeScott nails it.
  2. /etc/pam.d/* files will tell you what format a system encodes new passwords with, and should be accessible to regular users, which may be all you have.

Long version:

Most modern Unix and Linux systems use PAM, the Pluggable Authentication Modules, for handling authentication. As a result, the hashing algorithm used to encrypt passwords is usually defined in one of the /etc/pam.d/* files. Peeking at Ubuntu 14, I see it's in /etc/pam.d/common-password file:

# Explanation of pam_unix options:
# The "sha512" option enables salted SHA512 passwords.  Without this option,
# the default is Unix crypt.  Prior releases used the option "md5".
password    [success=1 default=ignore]  pam_unix.so obscure sha512

So, on this system, entries in the /etc/shadow file should have passwords starting in $6$. If I look at /etc/shadow as root, I can see that indeed, all (both) of the passwords on this system are sha512:

# awk -F: '$2 ~ /^\$/ {print $2}' /etc/shadow | cut -c-10

Pam being so flexible, you'll find it's in a different file on each type of system you look at. Under RedHat, it seems to be /etc/pam.d/system-auth, for example.

This tells you what password hash will be created when a new password is set on this system. The actual password hashes in use will vary depending on where or when they came from. If a system used to use MD5, and switches to SHA512, then not all the hashes change - the old hash remains in use until the next time a user changes their password. If hashes are copied in from elsewhere (yes, it happens) you can get a real melange of password hashes. That's why the format used is encoded into the hashed password string (the $6$, $1$, etc. etc.) - so the system knows how to test against it.

So the only ways to know for sure what hash you're using is to either have root privileges (and look at your hash in /etc/shadow), or to see what the system default is (in /etc/pam.d/*) and change your password so that the default will apply to you.


As @grawity pointed out in the comments, older Linux systems/distributions may still honor the ENCRYPT_METHOD setting in the /etc/login.defs file. (This file and setting is still there on new systems; it's more-or-less silently deprecated if PAM is in use).

And even though Solaris used PAM the last I checked, a little Googling suggests that to change the default password hash type you should instead change CRYPT_DEFAULT in /etc/security/policy.conf.

AIX laughs in the face of what passes for Unix standards these days, just as they always have. The pwd_algorithm setting in /etc/security/login.cfg will do the trick for AIX 5.3+.

In general, though, any Unix variant that supports more than DES will provide some method for configuring the system default. If you run into systems not mentioned here, tweak this Google search and see what you can find out.

| improve this answer | |
  • 1
    To be distro-agnostic, always start with /etc/pam.d/passwd, as that's what the passwd tool loads. Then just follow "include" and "substack" directives. – user1686 Jan 3 '15 at 23:33
  • 2
    Also, some distros (cough slackware) still run without PAM; in that case, /etc/login.defs will have the relevant configuration. – user1686 Jan 3 '15 at 23:34

If you have root access, use it to cat /etc/shadow (on most Unix flavours) and take a look at it. The second field in the file is the hashed password for each user, and it is generally separated by $ signs into three parts, which are the hashing algorithm, the salt and the hash itself (if it doesn't have the first section then it's using the default hash algorithm, which is DES). $0$ is DES, $1$ is MD5, $2$ and $2a$ are Blowfish, $3$ is NT Hash, $5$ is SHA-256 and $6$ is SHA-512.

| improve this answer | |
  • Just out of curiosity I'd love to see an equivalent of this without root access. – user42178 Jan 3 '15 at 18:55
  • 1
    @AndréDaniel Any method for obtaining contents of /etc/shadow without being root would be considered a vulnerability. So don't count on being able to figure out those parts of /etc/shadow which depend on the users password or the random salt. You can look for configuration files which decide how a new password would get stored, but they won't prove anything about the algorithm used for existing entries. – kasperd Jan 3 '15 at 22:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.