Expiring password after a time limit has elapsed

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

Hello.

I am still relatively new to perl and have hit a few bumps along my way to finishing my program. Some background to my question: There are two files: info.html and run.cgi. A user navigates to http://www.mysite.com/info.html and enters a user ID. The user ID is given to run.cgi, which creates a temporary, random password on a remote server. I output the userID, the time of the request, and the server name to a log file.

Currently, I am using a cron to run another script, pass.pl, every minute. pass.pl simply checks the time the password was created (from the log file) and compares it to the current time. Once the password is one hour old, pass.pl generates a new, random password and renders the user's account inaccessible.

Is there another way to perform this password change/time checking? A cron runs continuously, and I would like to try something a little more efficient. I was thinking of starting the pass.pl script at the end of the run.cgi script. I don't know if that is the correct route to go, and was hoping someone would assist me in finding another way to change the password. I've heard of using a daemon, but how would I go about doing this from within the current cgi file?

Ideally, I would want to have a new script checking the password's time, and running the pass.pl script after one hour. The new script would automatically be activated after the run.cgi is processed, and would stop after one hour.

How would I go about doing this?

Thanks in advance!

Comment on Expiring password after a time limit has elapsed

Replies are listed 'Best First'.
Re: Expiring password after a time limit has elapsed by kyle (Abbot) on Jan 18, 2008 at 17:46 UTC
What is the remote system that the accounts are created on? Does it have any password expiration feature that you could use? How I'd normally handle this if I were writing the authentication mechanisms (and it sounds like maybe you're not) is to store the expiration time with the password and check it at the time the user tries to gain access. If you can't do that, and you really want to have a daemon, look at fork and Proc::Daemon. What you'll do is create the account, fork off a daemon, and the daemon will sleep until the expiration time, at which point it can handle the expiration. It sounds as if what you're doing now is working, though. I don't know how active this system is, but if it's very active with many accounts in an "about to expire" state, then you're going to have a sleeping daemon for each. That could be quite a waste of memory. Also, if the system dies, the daemons die with it, and all your expiration information goes out the window. Just some things to think about.	[reply]
Re: Expiring password after a time limit has elapsed by NetWallah (Canon) on Jan 18, 2008 at 18:35 UTC
kyle (++) has given you an idea regarding storing the password expiry information on the SERVER side. I would suggest that an alternative is to sore that information on the CLIENT. Subject to security requirements, cookie availability, and limitations of code complexity, I think the easiest would be to store the expiry timestamp as a cookie on the client. Encrypt this with MD5 or more complex, if necessary. If the cookie you receive has expired, does not exist, or is invalid, you have detected an expired/invalid password situation, with very minimal server overhead for checking. "As you get older three things happen. The first is your memory goes, and I can't remember the other two... " - Sir Norman Wisdom	[reply]
Re: Expiring password after a time limit has elapsed by CountZero (Bishop) on Jan 18, 2008 at 20:59 UTC
On a low traffic website I wrote, I check the expiry of the sessions / passwords with every hit BEFORE I do anything else. It is a simple SQL-command to delete all session /password info which are past their "sell by" date. It does not seem to slow-down noticeably the site. CountZero A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James	[reply]