how does `crypt` or `htpasswd` compare encryption?

[roswell1329]

This may be a silly question, but I've never really considered it and encryption isn't my strong suit. Everywhere I've read about encryption tells me that `crypt` is a one-way encryption algorithm in that there is no way to de-crypt the final result. The only way that the system can match on a password that has been encrypted with `crypt` is by encrypting the attempt, and comparing the two. However, when I use a similar encryption program, `htpasswd`, I get the following results for the same password:


sam:N650zSYVOqNEs
frank:09HzAwnxhkqlU


Both users have the same password -- "dumb". Why does the resulting .htpasswd file contain such different strings?

[th3>kLuTz]

I don't know much about encryption. I think though, that the reason they are different is because the name of the user is probably somehow added to the equation when encrypting the password. If I'm wrong, someone plz let me know :)

[roswell1329]

Hmm...thanks for the suggestion th3>kLuTz, but after reading your post I created an .htpasswd file with "sam" as the username and "password" as the password. Then I deleted that file, and did the same thing with "sam" as the username again and "password" as the password again. Here were the results:


sam:8d5JMrXY/9kR.
sam:qYG5YoSvmy39A


It may be that the timestamp has something to do with the algorithm, but then I wonder, how can you compare any two passwords unless the attempt is entered into the system at the exact same time as the original entry?

[8*B@LL]

well perhaps those two results are equivilant when they are evaluated by the algorithm? just a shot in the dark though.

[droby10]

you might try cross referencing the salts used ie.

if crypt() was used to create the entry:
sam:8d5JMrXY/9kR

and htpasswd yielded:
sam:qYG5YoSvmy39A

then try running crypt with a salt of 'qY' and see if it matches what htpasswd is giving out: as i recall the salt used in htpasswd is random.

[roswell1329]

Actually they were both created with htpasswd. I merely assumed that htpasswd was using the crypt() function.

[droby10]

i probably didn't make as much sense as i had intended. your secondary question here was how can it compare two differing values? the answer is that it uses the same salt.

in the initial encryption htpasswd uses crypt or des derivative to encrypt the password using a random salt value.

in any comparison thereafter the encrypted password is read first to retrieve the salt used in the initial encryption and then crypt is called to create the comparison value.

[slarty]

Crypt takes two arguments, the salt and the password. It outputs a single string.

The salt is two characters long typically, and is included in the output string. The salt is to prevent a casual observer looking at the encrypted password file from determining if two users' passwords are the same.

The same password/salt pair will always result in the same output, but if a different salt is used, even the same password will produce completely different output.

The salt is typically chosen randomly each time the password is set or changed. This means that except in very large password files, two users are unlikely to have the same password salt.

Some programs which use crypt may use a constant value for the salt; this is ok too, but it makes cracking the file much easier, as an attacker can simply encrypt the entire contents of a dictionary with the constant salt (offline), then very rapidly crack any passwords which are in the dictionary.

[redgore]

The passwords will always be different. If you look at all the algoryphms (did i spell it right??) you will realise for a single letter of the password there is about 62 possibilities as to what to make it. Add more letters into the equation and this increases. This is normal so dont worry.

[darkes]

Originally posted here (http://www.AntiOnline.com/showthread.php?threadid=#post) by redgore
The passwords will always be different. If you look at all the algoryphms (did i spell it right??) you will realise for a single letter of the password there is about 62 possibilities as to what to make it. Add more letters into the equation and this increases. This is normal so dont worry.

Err, no, it should be "algorithms" :D

btw lots of info on the net about various encryption algorithms.
You have two very different methods:

(1) Symmetric encryption (e.g. DES, one time pad) - both parties need to have a copy of the key to encrypt/decrypt the message, which may include the user name as well.

(2) Asymmetric encryption (e.g. PGP, AES), where you make your public key freely available, but the private key, which is used to encrypt/decrypt the message cannot be obtained easilly from the public key that has been made available.

[roswell1329]

Originally posted here (http://www.AntiOnline.com/showthread.php?threadid=#post) by droby10
i probably didn't make as much sense as i had intended. your secondary question here was how can it compare two differing values? the answer is that it uses the same salt.

in the initial encryption htpasswd uses crypt or des derivative to encrypt the password using a random salt value.

in any comparison thereafter the encrypted password is read first to retrieve the salt used in the initial encryption and then crypt is called to create the comparison value.

That was it! Thanks, droby10! I wrote a perl script using the crypt() function to encrypt 2 identical passwords for 2 identical usernames using the same salt for both. Here's what I got:


sam:cY8D5Z5ZOhg1.
sam:cY8D5Z5ZOhg1.


I also found a perl script that mimics how the `passwd` program compares against passwords in the passwd file:


$pwd = (getpwuid($<))[1];

system "stty -echo";
print "Password: ";
chomp($word = <STDIN>);
print "\n";
system "stty echo";

if (crypt($word, $pwd) ne $pwd) {
die "Sorry...\n";
} else {
print "ok\n";
}


Basically, $pwd is grabbing the encrypted passwd chunk from the password file (used as the salt), and using it to encrypt the attempt. If the resulting strings match -- groovy. If not, go away. :bigsmile: That makes much more sense to me. Thanks everyone for your input!

[jethro]

htpasswd uses DES altered for Apache.

[yanksfan]

quick question: even though the crypt function is one way, does that mean it's failsafe from retrieving the original string (i.e password) that was encrypted? Has anyone ever actually decrypted anything that has been encrypted with crypt()?

-Mike

[roswell1329]

Taken from the UNIX System Administration Handbook, Third Ed., p.656
In the 80s, there was at least one way to decrypt passwords posthaste, but run-of-the-mill hackers had to be content with using the crypt library routine to encrypt dictionary words for comparison. A "fast" machine in the 80s could do a few hundred encryptions per second. In 1998, John Gilmore of the Electronic Frontier Foundation and cryptographer Paul Kocher cracked a 56-bit DES key in 56 hours using a brute force search. Recent proposals suggest that a $1 million special-purpose computer could crack any 56-bit DES key in just a few hours.

So, the answer is yes, but even a low-bit encryption would take a VERY long time on a workstation or PC. :bigsmile:

[ammo]

Originally posted here (http://www.AntiOnline.com/showthread.php?threadid=#post) by yanksfan
quick question: even though the crypt function is one way, does that mean it's failsafe from retrieving the original string (i.e password) that was encrypted? Has anyone ever actually decrypted anything that has been encrypted with crypt()?


It can't be done. There's not enough information in the resulting hash to reconstruct the password.

You could, however, try to brutforce the password: that is try every possible password, encrypt it and compare. Without the salt, bruteforcing passwords would be much easier as you could build lists of password/hash pairs. However because of the salt, such a list would be unbelivably big since for each password there are many resulting hashes (one for each possible salt...). So building such a list (and then searching it) would be EXTREEMLY ressource intensive and is considered pretty much undooable (except perhaps for the NSA! Who knows what they can do!).

Ammo