Re: Re: Re: Crypt::DES returns same string

Ahhhh ok, I think i'm begining to understand. DES cant do this. Given a key and plaintext, DES will always produce the same ciphertext.

What I think you're after is session management.

The basic gist is:

You have already a bunch of users
The user logs in and you give them a token
Each page refresh you check their token against a list of known tokens. If its in the list, let them view the page, otherwise direct them to log in again

The token can be an MD5 hash. The list of users can be in a database or in a flatfile, and you should have a sessions table (or ff) which would have the token and the user_id in it.

Each page view you get the token (from a CGI param or from a cookie) and look it up in your session table.

Comment on Re: Re: Re: Crypt::DES returns same string

Replies are listed 'Best First'.
Re: Re: Re: Re: Crypt::DES returns same string by learn_forever (Acolyte) on Mar 30, 2002 at 23:10 UTC
Aye Aye Sir ! You are right there. But instead of managing my sessions and then managing to expire them etc, I thought a simple scheme would be in each subsequent chained script (say logon.pl, then menu,pl then user clicks submenu.pl and so on) -> I would grab the encoded string ecode it and get the actual userid when I pass the userid to next script I re-encode and substitute. This will even have better security as each time a new string is generated for same userid so even a session string can not be stored by malacious user I tried it successfully using my own crypt function and decrpyt function where I changed te salt randomly. But I was not sure if this is a secure enough way (and tested) , so I would like to rely on time-tested modules like DES or MD5. Does any of these have this type of functionality? Thanks	[reply]
Secure Session management (was Crypt::DES returns same string) by Ryszard (Priest) on Mar 30, 2002 at 23:36 UTC
I reckon the best method of identifying a user is send an arbitrary token to the browser, and storing the token (server side) against the user_id. One of the no-no's in web based applications is storing user data on the client, encrypted or not. The reason for this is you have no control over the information once it has passed to the client. For example, if you are writing an applicaiton and send a session id to the client that is a two way operation, someone could sniff the packets, grab the information and reverse it. Once they have reversed it they may hijack the session. What you dont know are the resources your attacker has (They may have a cluster of E15k's at their disposal). If you use a what is considered a one way function (such as MD5 or SHA-1) it is relatively impossible for an attacker to derive the meaning of your id. If you then store your generated sess_id along side your user_id at the server, you have complete control over the information. Identifying the user is as simple as looking the sess_id up in a database. OTHO if your attacker has a cluster of E15k's you've got a bigger problem on your hands.. ;-)	[reply]