How to: Ensure your Linux account passwords are strongly hashed

While reading around on how to break into Linux accounts the other day I stumbled across the interesting tidbit of information that the password hashes stored in the /etc/shadow file can be hashed using different methods, some more preferable than others.

Here’s an extract from my shadow file:

From looking at the information in man shadow, there are 9 fields in the following format:

  • Account name,
  • Password hash. A value of ! or * indicates the account cannot be logged in with, but may still be used by processes, and !! means the account has expired
  • Date of last password change (expressed as the number of days since Jan 1, 1970),
  • Minimum password age before change (minimum days before you can change the password),
  • Maximum password age before change (maximum days before you must change the password),
  • Password warning period (how many days before the password expires should the user be warned their password will expire soon),
  • Password inactivity period (the number of days an account may still change their password after expiry)
  • Account expiration date (expressed as the number of days since Jan 1, 1970), and finally,
  • A reserved field

So, taking the pulseaudio account pulse as an example, pulse:*:15089:0:99999:7::: means:

  • Account name = pulse,
  • Account may be used but cannot log in,
  • Password set 15089 days since 01/01/1970 (which will be around May 2011),
  • 0 days must elapse before password change,
  • 99999 days (so roughly 273 years) may elapse before password change,
  • 7 day password warning period,
  • No password inactivity period,
  • No account expiration date,
  • No data in the reserved field.

All fair enough – but now take another look at the test user account:

The password field has a stored password hash (which in this case is a SHA-512 hash of the phrase thisisstupid2) – and the first three characters are $6$. This is where the strong hashing comes in…

Choose Your Hashing Algorithm Wisely

There are a number of first-three-character combos which mean different things, and some are definitely better than others:

  • $1$ – password is hashed with MD5,
  • $2$ or $2a$ – password is hashed with a blowfish variant,
  • $5$ – password is hashed with 256 bit SHA-2 bit resulting in 32-byte output, and
  • $6$ – password is hashed with 512 bit SHA-2 resulting in 64-byte output.

MD5 is broken, by which I mean it can be manipulated to give the same hash for different sources. SHA-256 and SHA-512 on the other hand are significantly stronger and to the best of my knowledge do not currently have working attacks, so they’re definitely the way to go. There’s a great article on shadowed passwords by Aaron Toponce over at GuruLabs which will tell you pretty much anything you might want to know, and which can be found here.

Going back to my own experience with this, when I checked some accounts on my VPS (which runs this site) the other day, I found that some of the hashes started with $1$, so were hashed with MD5. The fix for this? Simply reset the password and the newer, stronger hashing algorithms will be used.

You can reset the password for any account by issuing the following command and then providing a new password:

For example:

After this, check your shadow file to ensure your hashes start with the desired prefix. Once they do your machine will be a little bit more secure, and it isn’t that much of an ordeal to achieve.

Cheers!

4 thoughts on “How to: Ensure your Linux account passwords are strongly hashed”

  1. Interesting… after doing a new install of Ubuntu 11.04 this weekend I thought I’d check the default setup. I can confirm that the distro does a $6$ encryption straight away.

    1. Good to know, cheers!

      It’s definitely $6$ on my copy of 11.04, too – but for some reason some of my VPS accounts were $1$, so MD5! Curiouser & curiouser =D

      1. That depends on what distro THEY are using, and how old it is.

        I would imagine that they wouldn’t upgrade TOO often, businesses tend to lie far behind the curve in these things. Just think of all the hassles they get whenever they change the OS of their servers? Something that I wouldn’t do without being forced to, something like the security updates being at EndOfLife.

        It’s simple business logic, if the system works then don’t mess around with it. Nothing worse than riling up your customer base every six months for an upgrade, which most of the time would yield very little benefit to the business.

        Even when support is at EOL they would likely add it to their TODO task list and fit it in whenever it’s best for them.

        1. True – the VPS distro this is hosted on definitely isn’t the latest and greatest (and I’m fine with that), so I guess that means I’d have to find out at which version of Ubuntu they switched from MD5 to SHA hashes.

          Saying this, because it’s my VPS, I’ve updated the software on it as I’ve gone along, so maybe that’s something to do with it as well. You definitely can’t do a kernel upgrade (as part of a dist-upgrade) because how would that interact with the Xen stuff? [like an axe to the head, I’d imagine!]

          Knackered my site the other day trying to twiddle with options and it just lost all the css config… Still chasing issues in css land, but at least I get to go through and give it a much needed cleanup… It’s been non-validating since day 1, so it’s well time I did something about it. (i.e. Do you like the .commentlist unordered list thingies to the left of embedded comments? Me neither! Haw haw… =P )

Leave a Reply

Your email address will not be published.