Realized, entirely by accident, that the hashing/encryption algorithm used for user passwords in the shadow file is horribly insecure and out of date.

After initial install the default algorithm is set to DES!!! Which has a 8 character limit. So if you have a password like:

googleit4359#$@

someone could log in via ssh with:

googleit

You go from a great alpha-num-special to an all alpha-lowercase 8 character password. This is obviously much easier to bruteforce. I found this out by accident when I hit enter too early during an ssh login.

I've since changed the algorithm to md5 and re-hashed all the passwords. I suggest everyone check their distros to see if they are affected as well.

Addendum:

This is specific to Linode's CentOS image and not a problem with CentOS as a distribution. I've installed from iso and md5 is the default.

I can confirm Ubuntu 10.04 LTS uses SHA-512 hashing on my logins. Plain old MD5 on root. DES shouldn't even be an option anymore, but I guess it would be $0$ in /etc/shadow?

Debian 5.0 is using MD5 by default. Though it looks like possibly this stackscript which uses the chpasswd command creates a DES encrypted password.

http://www.linode.com/stackscripts/view ... riptID=165

CentOS 5.5 32-bit here. Stock install (of ~5.3 which has been upgraded over time). All accounts use MD5 hashes.

Might want to look under /etc/pam.d/ to see if you've modified something.

It was DES on two different accounts both 5.5 32bit. I DID modify it to md5 AFTER discovering it was only DES by default. My idea of a fun time isn't blindly changing system-auth pam settings.

I deployed CentOS 5.5 32-bit, added a user with useradd, then set its password with passwd. It showed up as MD5:

jsmith:$1$taiOHB01$0jEFRkUrlPx2cGo67f2tQ.:14993:0:99999:7:::

I blame chpasswd. Debian dealt with something similar many moons ago, so clearly chpasswd figures out which algorithm to use from "somewhere else".

When we make a distribution, we don't change things like this; we modify the bare minimum to get it working on our platform. I definitely didn't get an option about it during installation, and didn't modify anything with reference to it.

This is truly weird. Two seperate linode accounts two seperate VPS instances. Both installed with CentOS 5.5 32bit and all users created with useradd and password initially set with passwd. All users were DES. I don't know what to say, I'm glad it's not affecting anyone else but I kinda hope another user running CentOS 5.5 32bit runs across this post and finds they are using DES too.

I can confirm that I see this on my CentOS 5.5 Linode. I haven't seen this happen on RH-based machines for YEARS, so this can only be some kind of misconfiguration in Linode's image template. I don't know the PAM stuff enough to know exactly what it is though.

OK, I fired up a fresh 512 Linode and tried the same things I did on my own Linode. I have never used chpasswd in my life, only passwd. Curiously I am unable to reproduce this on a fresh Linode.

This did happen to all accounts where I have changed the password after I moved in during December. I had cut & pasted all of the relevant users into /etc/passwd /etc/group and /etc/shadow. In cases where I used passwd to change a user's password it somehow set it to DES.

Finally! I tried to tell you people I wasn't insane nor newbish. For anyone who doesn't know the offending line is within the /etc/pam.d/system-auth file:

password sufficient pam_unix.so md5 try_first_pass use_authtok nullok shadow

The passwd command is configured to make use of pam for password resets. In the default Linode CentOS 5.5 image the md5 argument is not supplied(or at least wasn't). As a result the default encryption method chosen when creating a password is DES.

Just add the md5 and re-hash all your passwords. Just glad my good name wasn't further tarnished.

Does the root password in the linode dashboard also need to be reset in addition to resetting the user passwords with the password command?

Thanks for reporting this problem.

The Linode dashboard password is completely separate from the passwords used to log in to your virtual machine. So it does not need to be reset for this reason.

Thanks.