how does `crypt` or `htpasswd` compare encryption?
Page 1 of 2 12 LastLast
Results 1 to 10 of 15

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

  1. #1
    Senior Member roswell1329's Avatar
    Join Date
    Jan 2002
    Posts
    670

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

    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?
    /* You are not expected to understand this. */

  2. #2
    Senior Member
    Join Date
    Jun 2002
    Posts
    144
    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
    M$ support is like shooting yourself in the left foot and then putting a band-aid on the right one.

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

  4. #4
    Senior Member
    Join Date
    Aug 2001
    Posts
    356
    well perhaps those two results are equivilant when they are evaluated by the algorithm? just a shot in the dark though.
    -8-

    There are 10 types of people in this world: those who understand binary, and those who dont.

  5. #5
    Senior Member
    Join Date
    Jun 2002
    Posts
    165
    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.
    -droby10

  6. #6
    Senior Member roswell1329's Avatar
    Join Date
    Jan 2002
    Posts
    670
    Actually they were both created with htpasswd. I merely assumed that htpasswd was using the crypt() function.
    /* You are not expected to understand this. */

  7. #7
    Senior Member
    Join Date
    Jun 2002
    Posts
    165
    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.
    -droby10

  8. #8
    Senior Member
    Join Date
    Jan 2002
    Posts
    1,207
    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.

  9. #9
    Senior Member
    Join Date
    Sep 2001
    Posts
    201
    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.

  10. #10
    Senior Member
    Join Date
    Aug 2001
    Posts
    485
    Originally posted here 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"

    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.

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