in reply to Length of Crypt::CBC result

Given that no one has mentioned it yet, encrypting information and sending it back to the browser is generally considered bad form. (I'm making the assumption here that your not using said information as a sess_id).

The reason it is generally considered bad form is you have no control over the data:

  1. Consider a replay attack. Someone gets the encrypted information stores it for a while and sends it back.
  2. Consider a crack of the cypher. Someone determines the plaintext, modifies it and sends it back (not to mention your entire application is now exposed).
  3. Consider a corruption. Someone arbitrarily changes some bytes and sends it back. It may decrypt and crash (or worse!) your application.

For these reasons (and others) the safest method of managing state, is by sending a non determinate token to the browser as a cookie (or in a url), then retrieving the token and looking up the associated details.

You now have complete control over when, where, how and the manipulation of the data.

Replies are listed 'Best First'.
Re: Re: Length of Crypt::CBC result
by talexb (Chancellor) on Apr 04, 2002 at 14:48 UTC
    The reason it is generally considered bad form is you have no control over the data:
    1. Consider a replay attack. Someone gets the encrypted information stores it for a while and sends it back.

      I have other measures to counter a replay attack -- the data can only be entered into the database once. Replays fail if the record already exists in the database.

    2. Consider a crack of the cypher. Someone determines the plaintext, modifies it and sends it back (not to mention your entire application is now exposed).

      Interesting point -- I'll amend my approach to modify the data before encryption, then reverse that process when it comes out the other side.

    3. Consider a corruption. Someone arbitrarily changes some bytes and sends it back. It may decrypt and crash (or worse!) your application.

      I'll have to live with that .. it's been a while since I saw a web page corrupted.

    --t. alex

    "Here's the chocolates, and here's the flowers. Now how 'bout it, widder hen, will ya marry me?" --Foghorn Leghorn

[reply]
Re: Re: Length of Crypt::CBC result
by Anonymous Monk on Apr 04, 2002 at 17:29 UTC
    This is NOT a bad idea. 1) Associate an expire time, and ip address with the data being stored. 2) Also change the private key every day. 3) eval it. Why use a session cookie, or other means when you can do the above?
[reply]
      Ok, so there are methods that can be used to make the data more secure (altho' using an IP address is not a great idea).

      My point is control. Once you send the data out to the browser you lose control.

      If you have a public web server, most of your server side security should already be done. Why create more processes and procedures if you dont need to? The more processes and procedures you add, the greater the chance something could be missed.

      There is a reason why most web apps use a non determinate token and associated session management - it works and it simple to do.

[reply]

In Section Seekers of Perl Wisdom