Secret Hidden Data

[SilverBean]

I'd like to have a "brief" discussion as to options for putting secret and hidden data on a web page. As I near the end of my first significant web application using a MySQL server and serveral Perl/CGI routines I feel compelled to add some "extra" things which may come in handy in the future.

I'd like to first state that this has nothing to do with on-line commerce or the use of encrypted data for credit card purchases. Though I will touch on encryption.

I already have the password in a hidden text field on my form that gets passed from routine to routine as the user submits data. I must say I really wouldn't mind an alternative to the function crypt. I've seen it only use the first 8 characters in order to generate the unique string and that seems to me to be a quite limiting thing. I thought of breaking it into 2 groups of up to 7 characters each, easy enough to implement -- but that just seems silly.

Although I don't have any specific examples of what exactly I want to do in the future, but I 'd thought it would be nice to include the date and time the user logged in on the form as a hidden field -- just so I can check for cached pages and force another log in. Another idea was to maybe save some user settings, preference flags. Did I mention I really can't stand cookies? I have used them and know what they are.

Those are pretty weak example so lets not focus on why I want to do this maybe just on how?

I'm just looking for an "easy" way of putting some data onto a hidden field on a form. A means of scrambling it just so it's not amazingly obivous to prying eyes as to what it is and what it might be. I'd like a reliable means of being to regenerate the scrambled data not necessarily going to encrypt to decrypt and back again. A means of scrambling it so that for specific data I would get only 1 answer.

Ok so the options are:

A.) Crypt function - limiting to a unique 8 character string. My current working solution - not impressed.
B.) Crypt module: Tons of them out there Crypt:CBC, Crypt:CFB, Crypt:IDEA, I have done encryption for credit card purchases. I've heard this eats up processing time and seems way overkill for what I want do - but I haven't ruled it out.
C.) Digest - Again seems like alot of them out there they generate a 128 byte fingerprint? I'm worried because I've heard these go obsolete and get replaced. I'd think I'd be fine with an older one but I just worry that my pay for host service might replace an older one with a newer one and blow me out of the water. By that time I'll probably have my own server but still would like to avoid. What is the difference between Encrypt vs. Digest? Some Digest don't produce specific digest for all data? Which ones are the ones that do?
D.) None of the above. What is wrong with me taking a data string of some known length using another key string and EXORing them together, reversing, padding and adding 1? I think this is really all I need as long as I could get the same result all the time and that the result would be specific to one string of data (all other being the same). I mean I'm not going to post the link to my site here but I think this would be fine for my purposes. for now.

Any Suggestions? I've been all over CPAN, perl.org the expertise is certainly there if I wanted to do Encrypt or Digest, etc. but what I'm really looking for is for somebody to give me the pros/ cons of options A-D kind of fill in the gaps.

 

[travs69]

You are passing the password from page to page?? Even encrypted that seems like a bad idea.

Why aren't you using sessions and cookies? User logs in and you create a session ID. Session ID is stored in the cookie and all data about the user is stored in the session on the server. Set the sessions to expire after 30 min of non usage.

You can then move all of you encryption to the back end.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Travis - Those Who Say It Cannot Be Done Are Usually Interrupted by Someone Else Doing It; Give the wrong symptoms, get the wrong solutions;

 

[brigmar]

Amen. You don't need to store anything but a session ID in the cookie. Have all your "stuff" at the server end. There's nothing "secret" in a delivered web page.

In no particular order:

C) Digests and hashes are one-way functions; you won't be able to regenerate the source data from that information. The only way they would work is if you held the session information at the server end and compared the digest/hash of that versus what the client is sending. But if you're doing that, you already have session information stored at the server end which leads you back to just having a session cookie.

A) Agreed. Not much use.
B) Why is processor use an issue? Surely the length of the data you need to encrypt is short.
D) That would be quick'n'easy, so long as you don't mind prying eyes from reverse engineering your 'encryption' and effectively spoofing sessions.

 

[MillerH]

Did I mention I really can't stand cookies? I have used them and know what they are.

Cookies are a technology, there's no reason that I can think of to "hate" them. They are also the accepted means of maintaining state with http. So shat is the basis these feelings toward this feature?

Anyway, to avoid a psychological or philosophical discussion, I'll simply tell you want I use.

Cookies with a non-encrypted user id appended to an Crypt::Rijndael encrypted string. The plain text user id is intended simply for easy inclusion in the access log for every request. The encrypted string contains, the user ID again, the session ID, the IP address or range of the user, and a Digest that is a combination of the user id, session id, ip address and some random information.

- Miller