web-yogini has asked for the wisdom of the Perl Monks concerning the following question:

Namaste Brothers and Sisters,

I have this http::Request::Common script that interfaces into my ISP's main admin page to create new pop boxes. Unfortunately, I didn't originally write it, and there is this strange encryption of the password that I can't figure out. The snippet looks like this:
$request = $ua->request( POST $ServerURL, [ form_aname => $in{username}, form_passwd => $in{password}, form_result => 'true', menu => 'add_mbox', user => 'whatever', auth => '*:1yIM9F71yIM9v', account => 'whatever', mbox => '' ] );
The true password is auj8dhw5. If I place it as plain text, the script works just dandy. But, if I use crypt(), it comes up with a "GpxEdaMbUuvfY" which is an entirely different format. It doesn't work either. : (

Could my fellow seekers of truth please shed light on this contemplation?

Om Shanti Shanti

Web-Yogini

Replies are listed 'Best First'.
Re: What kind of encryption is this?
by arhuman (Vicar) on Mar 19, 2001 at 23:38 UTC
    The same plaintext (passwd) could produce several ciphertext depending on the salt..

    But could you be more precise : if the plaintext password works what is your problem ?
    (A lot of (bad) HTTP authentication is made with plain text password, it could be the case here...)

    Simple observation : the auth is really TOO REDUNDANT to be produced by a real/secure hash/crypt function ('lyIM9' repeated twice) so you can exclude all known good known crypto systems.

    "Trying to be a SMART lamer" (thanx to Merlyn ;-)
Re: What kind of encryption is this?
by TGI (Parson) on Mar 20, 2001 at 00:11 UTC

    When I tried crypting the password with the salt set to 1y, I got 1yl9nR3IDmrqY. So it's probably not crypted.

    Could it be base64? Basic HTTP authentication uses Base64 encoding to obscure password information. Of course this doesn't seem work either. I tried to use this script to unencode the string. No luck, I got a bunch of high ascii junk.

    Mostly useless, huh? Are you sure that you haven't got another plaintext password there?

    Update:

    crazyinsomniac, which assumption? I guessed the salt was 1y because the standard format for crypted output is two characters of salt, followed by 11 characters of hash (SSXXXXXXXXXXX). The mystery string is 1yIM9F71yIM9v, which just happens to be 13 chars long. By making the assumption and testing it, I was able to determine that the mystery string is not a crypted form of the plaintext password we were provided.

    Assumptions have their uses, when they are recognized as such. The problem with assumptions comes from not knowing what your assumptions are. Ask any mathematician.


    TGI says moo
      Well that's a pretty fscked up assumption, all such assumptions are.

      Who knows what the salt is, maybe it's static, you don't know.
      update:
      Heh, you're joking right? That is even more crazy. There is no standard, just because all lamers do it by default upon suggestion of the pod, don't make it standard. Anyway the standard you speak of also stores the plaintext password for so those dummies who forget it aren't lost forever(i mean apps that use that standard not crypt).

       
      ___crazyinsomniac_______________________________________
      Disclaimer: Don't blame. It came from inside the void

      perl -e "$q=$_;map({chr unpack qq;H*;,$_}split(q;;,q*H*));print;$q/$q;"

Re: What kind of encryption is this?
by orbital (Scribe) on Mar 19, 2001 at 23:41 UTC
    Assuming you have access to the code have you looked at the code for the ISP's main admin page this may offer clues as far as what the script is expecting as a proper format for the password.
Re (tilly) 1: What kind of encryption is this?
by tilly (Archbishop) on Mar 21, 2001 at 03:37 UTC
    Were I the ISP I would probably encrypt by taking the password, the name, and some sort of secret key, then taking the MD5 hash of that and truncating to the length I want. This is a well-known and simple procedure.

    That procedure has the following properties:

    1. You can verify a login.
    2. The key stored does not help anyone find the password.
    3. The keys generated for one user give no information on whether anyone else has the same password.
    4. Without the secret key there is no possible dictionary attack. Therefore the ISP is in a position to track any brute force attacks.
    Now I cannot prove that the ISP's programmers settled on the solution that I would. But I guarantee you that if they did then there is no way you are going to break their encryption mechanism...