Hello firends,
I have developed a portal for the intranet of my organisation with apache+mysql+php.
The users alongs with their passwords (md5 hash) and other details are stored in one of the mysql tables.
I have added one more table which records the login time and logout time of the users, with session id to keep track.
I find that in most of the cases login time and log out time both are recorded in the table but in some cases, the log out time is blank. I have found out that it is becasue these users have not properly logged out (that is, by clicking on the "logout" link). They have shutdown their machines without logging out. I feel it would be right if I automatically log out user after a specified time of inactivity.

How should I go about it ?

Any help ?

Thanks in advance.


Prabhat Soni

Let's say, hypothetically, that Mr B visits your portal and logs in. He looks around for a few minutes, then quits his browser. Since the PHP script has finished sending him the HTML, it has stopped running and has no way of knowing that the browser closed.

You could make the next iteration of the php script (even if it was dealing with another user), or an hourly cron job, check for logged-in users and formally log them out if they have been idle for too long. However, if Mr B spends half an hour reading one page, there would not have been any messages sent to the php script from that user, so the server would regard that user as idle. Mr B could be quite irritated at having to log in again, when to his eyes, he never left the portal.

The best solution I can think of right now is implanting a JavaScript in the portal, such that when the user quits the browser it will instead send them to the logout page (as if they clicked the logout button). There are problems with this, such as Mr B seeing the page change instead of the browser closing and getting irritated.

An example of this approach is the SAP software I use in some kind of employment function. When I hit the big red X (I have rudely assumed that you are familiar with the Windows XP window manager) to close the Internet Explorer window, a box appears which say "HOLY SHIT, SAP IS LOGGING YOU OUT MAN! HANG ON BEFORE YOU CLOSE ME!" Then, when I am safely logged out and the server is aware of the time of my logout, the browser closes.

You could use: or something like that.

I know bugger-all JavaScript, but if you look at the fancy shit advertisers can do with websites, I think with a bit of Google, a visit to a JavaScript forum and maybe some love, JavaScript can fix your problem.

Hopefully, however, someone here can come up with a better solution, as not all browsers support JavaScript, JavaScript is messy to deal with across multiple platforms, and some users disable JavaScript.

-pcweirdo.

If you're using PHP sessions, they are probably expiring after about 30min of inactivity anyway. Pcweirdo's javascript would help you get more accurate log out times, but I would also do an autoexpire like he explained.

Btw, unseeded md5 passwords are insecure. It's not active now, but there's a website you can submit md5sums to, and it'll crack them. Depending on what level of security you're hoping for, this may not be a problem. I would suggest using seeded SHA1 sums.

bluelightning, I like your reference to seeding, that is an excellent idea. Unseeded, a brute force attack is a lot easier, and MD5 (http://eprint.iacr.org/2004/199.pdf) and SHA1, among others, have known collisions to make the cracking easier. SHA-2 sounds like a good idea, but I'm not sure if the patents are a problem.

Also http://en.wikipedia.org/wiki/Passwor...ored_passwords might be handy for your specific case, prabhatsoni.

-pcweirdo.

Ok friends,
I will do some digging for this automatic log out.

Thanks a lot for advice about the md5; I have switched over to sha1.
But what is this stuff about "seeded" and "unseeded"..


Thanks a lot to all of you.


Prabhat Soni

With regular md5 or sha1, whenever you encode a password, the result is always the same. So sha1("mypassword") === sha1("mypassword").

Let's say someone decided to make a reverse lookup table of sha1sums to passwords for all passwords 8 characters or less. Then that person could just take the sha1sums and look them up in the table. It's likely one of the users would have a password in the table, so the attacker would crack it. In reality, optimizations of the reverse lookup table would be used, like rainbow chains, but for understanding the process you can think of them like reverse lookup tables.

Now instead of using sha1, let's say you make 1024 variations of sha1. For each user you use a random variation, and you store which variation you used. So the database would say Bob's password is 2972348298723432 in sha1 variation 732. Shadow passwords in Linux are an example of seeded passwords.

If the attacker wanted to precompute the sha1 sums, now he would have to do it for all 1024 of your sha1 variations.

As for how to seed the passwords, I'd append the seed to the password before I took it's sha1sum. So let's say the password was "secret" and 432 was randomly chosen as the seed. Store 432 and sha1sum("secret432") in the database.

Seeding can also prevent the subset of replay attacks where the attacker does not make any attempt to get the plaintext password, but instead uses the hashed password as a token to gain access. To avoid this attack, you need a different seed for every transaction, which amounts to a kind of challenge-response system.

-pcweirdo.