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

Recently, I looked at using cookies as a way of holding and storing password and user names so that a user will not need to apply passwords every time an update is required

I created an intranet based application that allows users to modify client records. Applying their password every time then need to update information. Many have asked why can't the system remember these passwords.

At first, I looked at using cookies, but based on troubles I am having and discusions here, it seems there are too many security holes.

What technologies could I employ to provide security, but limit users from only needing to login once. I would like a central screen that authenticates the user and then remembers the authentication credentials: each subsequent perl page can call theses credentials as needed. Therefore, I need a way to call and store the credentials safely, and another way to pull this information later. If I can get a way of creating two methods: one to store and another to recall, this allows me to easily add these methods to all scripts that require the authentication credentials

I am not looking for someone to do this for me. Rather, I am looking at suggestions of which technologies to use without complicting matters, adding more software, plugins and the like. I currently use apache, mysql, perl, cgi. Any past experiences would be greatful.

Once again, I seek the wise words of the Monks. Thanks in advance.

Simon

Replies are listed 'Best First'.
Re: Safely storing password
by valdez (Monsignor) on Nov 21, 2002 at 20:57 UTC
[reply]
Re: Safely storing password
by fruiture (Curate) on Nov 21, 2002 at 21:00 UTC

    I use to have an Object for a user storing these "credentials". It's created at startup of the program, the applications is called with a CGI object and that User.

    For this kind of session I always use Cookies, it's not generally insecure to store something in a cookie. It should not be the plain password, but have a look at your perlmonks cookie. In fact, that's the sense of cookies, that's their job.

    If you use Apache, you can also use WWW-Auth, so the Browser holds the session and Apache will verify users and passwords for you, so the script only checks $ENV{REMOTE_USER}.

    It's an intranet thing, so the Cookie thing is (imho) allright.

    --
    http://fruiture.de
[reply]
Re: Safely storing password
by Bilbo (Pilgrim) on Nov 22, 2002 at 01:51 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. 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.

[reply]
      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.
[reply]
      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?

[reply]

        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.

[reply]

Back to Seekers of Perl Wisdom