Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask

Crypt::CBC and verifying passwords

by geektron (Curate)
on May 19, 2004 at 17:41 UTC ( #354692=perlquestion: print w/replies, xml ) Need Help??

geektron has asked for the wisdom of the Perl Monks concerning the following question:

an application that i'm maintaining originally used Crypt:DES to 'encrypt' passwords for storage in a cookie to maintain a logged-in user. the app has decided to break with passwords longer than 8 bytes ( which i found out is a limitation of Crypt::DES -- it only handles 8-byte data ).

today I'm working on replacing the Crypt::DES with Crypt::CBC to allow for arbitrary-length password strings, but I can't get validation/ verification of the passwords from the cookie.

in the set_cookie routine:

my $cipher = Crypt::CBC->new( {'key' => 'stringie', 'cipher' => 'DES', 'iv' => 'vectory!', 'regenerate_key' => 0, # default true 'padding' => 'space', 'prepend_iv' => 1 } ); my $epassword = $cipher->encrypt_hex($password);
and the new $epassword is tossed into the cookie.

and later ( on subsequent hits to the app, essentially) we check the cookie pass against the DB pass like so:

my $cipher = Crypt::CBC->new( {'key' => 'stringie', 'cipher' => 'DES', 'iv' => 'vectory!', 'regenerate_key' => 0, # default true 'padding' => 'space', 'prepend_iv' => 1 } ); my $dbpwmd5 = $cipher->encrypt_hex($dbpw);
where  $dbpw is just fetched from the DB based on the username ....

and the values don't match. the newly encrypted $dbpw and the value from the cookie, that is.

after reading a couple other nodes ( Crypt::CBC question, Safe symmetric encryption - Crypt::CBC + Crypt::Blowfish? ) a block cipher (like DES) should allow for comparision.

Replies are listed 'Best First'.
Re: Crypt::CBC and verifying passwords
by Belgarion (Chaplain) on May 19, 2004 at 17:56 UTC

    There doesn't appear to be anything wrong with the code you presented. I just tried it by setting $password and $dbpw to the same value, and the encrypted values are both the same. I would image the problem is either in the database retrieval routine or the comparison routine.

    Perhaps you can provide more code or a more detailed explanation.

      i can't believe i didn't catch something so stupid.

      the keys and IV-strings are different between subs ...

      /me bangs head on desk repeatedly....

Re: Crypt::CBC and verifying passwords
by jdtoronto (Prior) on May 19, 2004 at 17:58 UTC

    I have used Crypt::CBC with Crypt::Blowfish in an application I am currently working on. I found that the result produced by encrpyting the same value on successive occassions did not match.

    It seems from your comments you are storing an unecrypted password and encrypting it for comparison. This won't work, well not if you are using Blowfish or similar. I think you would need to decrypt for comparison, thats where I ended up.

    Mind you, I did not investigate in depth, I found the problem and had to make it work.


      I had this same problem with blowfish and ended up needing to encrypt everything in the same file. The easiest way to do this was to create a module with two subs that handle encryption and comparision. I offer this untested code, which will hopefully point you in the right direction. Note I have not done any taint checking or etc. so this if very unsecure code, I'm also not saying this is a good idea just that it will work.

      "Cogito cogito ergo cogito sum - I think that I think, therefore I think that I am." Ambrose Bierce

Re: Crypt::CBC and verifying passwords
by Ryszard (Priest) on May 19, 2004 at 18:02 UTC
    You really should know that storing passwords client side in a cookie is a bad idea. Encrypt and compare baby, all the way, SERVER side.
      i'm aware that (unencrypted) almost anything in a cookie is a Bad Idea ™, but without rearchitecting this whole application, i'm stuck with encrypted cookies.

      encrypted in cookie, decrypted and compared server side.

Re: Crypt::CBC and verifying passwords
by Anonymous Monk on May 19, 2004 at 21:07 UTC
    'iv' => 'vectory!',
    Avoid using a fixed IV if at all possible. If two passwords have the same initial 8 characters, then their encrypted forms will also have the same first 8 characters. Random IVs avoid that information leak. See Practical Cryptography for more information.

    Some other posters on this thread seem to think that the random IV is a "problem" because it makes the encrypted form different every time you encrypt it. This appears to be because they don't understand the difference between an encryption function (like DES or Blowfish) and a one-way hash function (like MD5 or SHA1). The former can be decrypted so you can get the original back and compare originals. The latter can't be reversed, so you must compare the mangled versions.

    'key' => 'stringie',
    You're never going to be able to change the encryption key without breaking everything. That's bad.
    'padding' => 'space',
    In general, space padding is a bad idea (you can't recover the exact original message if it had trailing spaces), but for passwords it might be ok.
    my $dbpwmd5 = $cipher->encrypt_hex($dbpw);
    If it's not MD5, don't call it MD5.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://354692]
Approved by Plankton
Front-paged by Plankton
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (3)
As of 2022-07-02 01:18 GMT
Find Nodes?
    Voting Booth?
    My most frequent journeys are powered by:

    Results (102 votes). Check out past polls.