how does `crypt` or `htpasswd` compare encryption? - Page 2
Page 2 of 2 FirstFirst 12
Results 11 to 15 of 15

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

  1. #11
    Senior Member roswell1329's Avatar
    Join Date
    Jan 2002
    Posts
    670
    Originally posted here 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:

    Code:
        $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. That makes much more sense to me. Thanks everyone for your input!
    /* You are not expected to understand this. */

  2. #12
    Senior Member
    Join Date
    Nov 2001
    Location
    Ireland
    Posts
    735
    htpasswd uses DES altered for Apache.

  3. #13
    Senior Member
    Join Date
    Apr 2002
    Posts
    214
    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
    Either get busy living or get busy dying.

    -The Sawshank Redemption

  4. #14
    Senior Member roswell1329's Avatar
    Join Date
    Jan 2002
    Posts
    670
    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.
    /* You are not expected to understand this. */

  5. #15
    Senior Member
    Join Date
    Sep 2001
    Posts
    1,027
    Originally posted here 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
    Credit travels up, blame travels down -- The Boss

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

 Security News

     Patches

       Security Trends

         How-To

           Buying Guides