You know I'm curious, as I'm developing a site right now, I thought of an authentication process. I'll list it in steps:
1. User will appear at login screen. Instead of the username and password being the traditional -username and password, it will be more so.. like walking into a patdown in an airport before going threw the scanner.
2. Next perl script will execute a traditional mysql query match, and if true some random number gets generated and outputted to the user, this doesn't flag the authentication flag in the database yet though.. however a cookie is sent / a new CGI session.
3. The user will then be in more so of a.. contained locked down authentication state any dynamic data that needs to be updated by the user (just data stored in database) will be accomplished here.. Once the user triggers an event that we know the user is done updating the database of information, step 4 occurs..
4. The next perl script, will search for an email from user, validate the validation code, and username. If authenticated, the old cookie is destroyed and a new one is created and stored on users computer, if authentication failed the script prompts a new validation code and ask to repeate so user doesn't rage face from lossing data that they already updated (but this data was more so temporary).
5. ajax will bassically load a new page for user, and they have access to my main product/functionallity.. which is actually a dynamic and static sms web content group page where other users can be assigned to a group and see people's sms updates, which are actually commands that I parse in perl when their browser consistantly request a perl script that manages the messages. Really cool, I'll show you guys the link to a small demo if you want.
Now here is the catch, since their browser will request a different perl script every 5000ms to check for sms commands/updates, why not connect it to another more... logical script that destroys the user's session after 15000ms of no ajax requesting the mail processor?
I can't think of how to do this programatically, setting up this session destroy when a script is not executed after 15000ms.. The only thing I can think of is printing a variable to a perl script that would flag something not to delete session, but even that I'm unsure how to tackle it.
And the way my site is set up, is perfect for an operation like this to happen. This measure of secury flows in well with what the users are doing since its very specific, if that makes sense.
I would set up a cron job every minute that will delete all sessions with mod time older than 15000ms. And of course with each request, actualize the session mod time. Where is the catch? Or is there something I'm missing?
For my situation there are two problems with this:
0. I'd have to call my hosting company and probably go threw a major hassle to accomplish this. (cron jobs not supported)
1. I have other sessions from different systems that are located in the same folder, and would not be a good thing if those sessions would be destroyed every 15000ms lulz. I could store a flag in the session though, likewise if a user session for the project I originally posted about has a flag that is valid, it will be deleted by the cron job.
But like I said, I don't have authority on my server to run a cron job so issue #0 may not even be resolved.
Any other ideas? :s
Then I'd hook the deleting all invalid sessions to requests: Whenever a request comes, before anything else is done, delete the old sessions. You may want to store the last time the check was done and skip the step if it was less than a minute ago for performance reasons.
Of course you must remember the age of every session to distinguish the ones you actually want to delete.
Ok, I will store the time of last check into session and if it hasn't been checked in 1500ms it will be destroyed.
UserBrowser->AJAX request->perl(check time that is stored in session and skip if isn't at least <5000ms+latency (if it isn't then we know the user has someone attempting to do some damage since they just made the request 5000ms ago, then I can undergo some security checks, or just make sure they didn't have network lag) perform my sms mail script(i'll just integrate it into this handler), then store in session current time->output. Now search for sessions that do not have the time stamp less then 15000ms, validate if the user exists in database then remove session.
I think along side of the session time checks, I can have a series that increments so I keep track of how many request have been made, and validate that the request is in order to prevent mix ups and help tell if it's an attempt for hijacking or network issues.
Would this be the most efficient way? Or what do you think