Windows 7 has a twisted sense of security

I’ve got some lecure materials to sort out for Monday so I’ve booted into Windows to use Office, and thought a bit of music might be in order. So I access the NAS and noticed that I could quickly tidy up the letter E section of my music by dragging one folder into another – and then this:

Windoes 7 - yo safe!
Windows 7 – Safe!

Thanks for protecting me from moving a folder of mp3s there champ. And especially for the informative warning message specifying the nature of the problem.

It turns out that the issue is that windows is treating your intranet like the Internet and not trusting it, and you can fix this up by either twiddling the “Internet Options” of Internet Explorer or simply removing Internet Explorer entirely. The entire process takes less than a minute, and there’s a good guide on how to add your NAS to the known intranet addresses here: http://robotbutler.org/article/30.

Finally, as tempting as it is to remove IE entirely, might I suggest that this might not be a 100% wonderful idea (95%, yes..) because some (specialist / rubbish /silverlight-lovin’/ virtual-app-on-demand-type) websites will only work with IE, and if you really need to use one and don’t have it installed you’ll be miz.

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!