in reply to Safely storing password

I do use cookies to do something like this. When the user logs in I generate a session id string containing their username, a time-stamp and a random string. I store this id in the cookie and on the server. When they return to the site or view a new page the id in the cookie is compared to the one on the server. It is straightforward to add other checks to make the session id expire after a given time and things like that.

I think that from the security point of view this is adequate for many uses, though if you are sending log in details or session ids unencrypted it obviously isn't suitable for high security applications.

Replies are listed 'Best First'.
Re: Re: Safely storing password
by dingus (Friar) on Nov 22, 2002 at 10:16 UTC
    I do use cookies to do something like this. When the user logs in I generate a session id string containing their username, a time-stamp and a random string.

    One thing I like to add to the mix is the client IP address and force a relogin if the IP address changes. This is because in an intranet envronment (such as discussed here) IP addresses are unlikely to hange during normal use. If the IP address does change then this is an indication that someone may be trying to hack (so log the attept as well!).

    Typically its a good idea to not set the expiry time/date for a cookie because if yo leave it blank then it will expire at the end of the session - i.e. when the user closes his browser - which is normally the required behavious (log in once then not again).

    Dingus


    Enter any 47-digit prime number to continue.
Re: Re: Safely storing password
by Ryszard (Priest) on Nov 22, 2002 at 14:22 UTC
    When the user logs in I generate a session id string containing their username, a time-stamp and a random string.

    My 1st thoughts are, if i want my session to last forever all I have to do is alter the time-stamp... or do you mean you create a session_id based on these values?

      Yes, that's what I meant. The username and timestamp are mainly there to avoid the very small risk that two entirely random session ids could be identical. Even if I did use the timestamp to check the age of the session it wouldn't be a problem because if you altered the timestamp then the session id stored in your cookie would not match the one held on the server.

        After a bit more work, I realised the best way to have my scripts run secure are. THis works really well:
        apache_1.3.27.tar.gz mod_ssl-2.8.14-1.3.27.tar.gz openssl-0.9.7a.tar.gz $ cd openssl-0.9.7a $ ./config $ make $ cd .. $ cd mod_ssl-2.8.14-1.3.27 $ ./configure \ --with-apache=../apache_1.3.27 \ --with-ssl=../openssl-0.9.7a \ --prefix=/usr/local/apache $ cd .. $ cd apache_1.3.27 $ make $ make certificate TYPE=custom $ make install $ /usr/local/apache/bin/httpd -DSSL
        Make sure to export the secure public key to each client...