Hi there, I'm asking this here, since I'm mostly slackware orientated, though this could be considered not distribution specific and as such, I apologise.

I'm currently in the process of migrating content from an older system/version of slack to a not as old system with a newer version of slack and came across something, defying what I initially thought.

In an attempt to make things as invisible as possible for users, I decided to extract the passwords from /etc/shadow using John (done this many times before for numerous reasons, but ALWAYS ON THE SAME MACHINE).

I always thought this could only be done on the mahcinhe from which the /etc/shadow file originated, I thought that the encrypted passwords were somehow connected to a "key" unique to that particular machine/install but to my surprise, when the file was copied over to another machine and John run, all passwords were revealed (took a while, just saying).

So essentially, I achieved what I set out to and simply applied the passwords to the duplicate users on the new machine and for this part, job done, but I am left wondering how this is possible?

Very curious I done an experiment, same username on two different machines and the /etc/shadow file shows different information for the same user on both machines, so how can either machine "resolve" each others /etc/shadow file?
Obviously the passwords are not encrypted to any key or tied to the original machine (and if they are, how can it be found on a different machine), how does this work? (kind of annoying when something which you thought and believed in for a long, long time is discounted), a bit like Father Christmas eh...

Thanks in advance...

The password utility uses what's there in the shadow file. Your password string in that file consists of 3 elements:

1. hashing algorithm
2. salt
3. hashed password

These elements are separated by "$" characters, like this: $hashing_algorithm$salt$password_hash
In Slackware, the hashing algorithm has the value "1" which means (a variant of) MD5. Some other distros have "6" which means blowfish.
The salt string is randomly generated when you create/change your password.
The password hash (the 3rd element) is then calculated using the salt and your actual password when you type it in, using the specific hashing algorithm.

Check your password hash in your local shadow file. Write down the salt string. Then try this command:
and compare the result to the password hash stored in the shadow file. Should be the same!

This is how login works. The password tool takes your plaintext password and calculates the hash using the algorithm and hash which are stored with your hashed password. If the result of that calculation matches what's present in the shadow file, then you typed the correct password and you are allowed in. The algorithm is one-way, you can not recover the plaintext password from the data in the shadow file.

This is why you can just copy/paste a line in the shadow file from one computer to another, it will still work there.

Eric

5 members found this post helpful.

EXCELLENT, thanks!!!!!

Although it does answer the OP and marked as solved nonetheless I tried it on Slackware64 14.1. Slackware (14.0 & 14.1) now uses SHA256 to calculate the hash. I can't reproduce the hash with 'openssl passwd' so I googled and found out it doesn't support SHA256. I've found a solution but it's using Python and Perl script.

Following works on Slackware64 14.1
Thanks Eric.

2 members found this post helpful.

As of Slackware 14.0, SHA256 (with default of 5000 rounds) is used to hash new passwords. These parameters are controlled by ENCRYPT_METHOD and SHA_CRYPT_{MIN,MAX}_ROUNDS in /etc/login.defs.

Salt prefix $6$ corresponds to SHA512. I believe the blowfish patches to glibc use $2a$ for their prefix.

--mancha

Indeed, my mistake. The $5$ is SHA-256 and $6$ is SHA-512. My Slackware-current box creates a hash with $5$ prefixed which means SHA-256 was used. I carried over old passwords obviously...
GNU/Linux's python example line works for SHA hashing algorithms, openssl does not.

Eric

1 members found this post helpful.