Jump to content

How to avoid multiple login


mostafatalebi

Recommended Posts

Typically a "logged in" field in a database will monitor whether or not a user has logged in (0 - not logged in, 1 - logged in).

If someone else with the same credentials attempts to log in, validate the login using the "logged in" fields value.

This field can also be used with session timeout logic.

Link to comment
Share on other sites

I'd be pretty annoyed if I could only be logged in on one of my 5 devices at a time, I'm constantly going back and forth from my PC to laptop to phone to view PHPfreaks. If I had to login again each time I'd stop using the site. 

Link to comment
Share on other sites

Yes. You are right. But another question:

 

What happens to SESSION when the user exists the browser? I have made a session which holds a long set of characters added to the URL to make it work only within the session when the user is in the site. but now I did a test. I copied the URL with the random characters in it, and closed the browser, But when I reopened the browser and entered the URL, I saw it works. What shall I do? what is the problem? here is an example:

 

www.mydomain.com/gallery/archive/feb/user.php?dlurtg155wddv4g4th1k5

Link to comment
Share on other sites

Preventing multiple logins using the same account IS a valid concern. It all depends on the business needs. One scenario is if you are selling the application on a per-user license. If you allow multiple people to log in using the same credentials you will lose money. But, this is not a decision to make lightly as illustrated by Jessica's example.

 

If you really do need to prevent this, then you can implement a simple solution so when someone logs in and previous logins on that account would be invalid. In addition to creating a session when authentication occurs, store the Session ID in the user table. Then on any page requests you should already be doing a 'login" check you can query the user record to see if the stored session matches the current session - if not, log the user out. This will basically make the last login the active one.

Link to comment
Share on other sites

Quick clarification on the "close browser == delete session" bit of the discussion:

 

Closing the browser does not delete the session on the server, it deletes the session cookies on the client. Which means that the client cannot identify itself to the session any more, and thus the server will create a new session.

However, the session itself merrily lives on until the timeout is hit. At which point the garbage collector will have a chance to be invoked upon to delete that session, or maybe some other session. So the session can actually live for quite a while, even after the user has closed the browser.

In the meantime, anyone who sends the correct session ID to the server will be treated as if they were the original user. No matter if they aren't using the original client, or is on the other side of the world, using a completely different everything.

 

This is a very important distinction to keep in mind, especially when dealing with systems that require a minimum level of security. If anyone gets a hold of the session cookies, they are (for all intents and purposes) the original user that started the session. Unfortunately there's very little that can be done about that, at least reliably.

When it comes to session hijacking an account while the user is actively using it, it comes down to a question of whether convenience vs security: Do you want the user to be able to use multiple browsers/tabs/windows at the same time, and to what degree, or how difficult you want to make it for others to impersonate said user.

For the more insidious session hijacking attack, namely taking over an abandoned session, setting the session lifetime and GC probability sufficiently low/high (respectively) will help. Albeit, with a trade off of increased server load. The tricks used to complicate hijacking of active sessions will also have an positive effect on preventing this type of attack, but while the user is active it carries the same negative side effects.

 

Basically: It's a huge balancing act, with no definitive answer, I'm afraid.

Link to comment
Share on other sites

Quick clarification on the "close browser == delete session" bit of the discussion:

 

....

This is a very important distinction to keep in mind, especially when dealing with systems that require a minimum level of security. If anyone gets a hold of the session cookies, they are (for all intents and purposes) the original user that started the session. Unfortunately there's very little that can be done about that, at least reliably.

When it comes to session hijacking an account while the user is actively using it, it comes down to a question of whether convenience vs security: Do you want the user to be able to use multiple browsers/tabs/windows at the same time, and to what degree, or how difficult you want to make it for others to impersonate said user.

For the more insidious session hijacking attack, namely taking over an abandoned session, setting the session lifetime and GC probability sufficiently low/high (respectively) will help. Albeit, with a trade off of increased server load. The tricks used to complicate hijacking of active sessions will also have an positive effect on preventing this type of attack, but while the user is active it carries the same negative side effects.

 

Basically: It's a huge balancing act, with no definitive answer, I'm afraid.

 

But what happens when I need a very strict session control? not allowing users to explore the site using several devices. Each entrance to site must equal a sign-in. Being strict is due to the fact that my site has pay services, or in other words, it is a commercial website. Even I have not yet enabled cookies, since it increases the chance of hacking.

Link to comment
Share on other sites

Once again - if I paid for a site and was unable to access it from ALL my devices, I'd cancel immediately.

 

Look at what Hulu and Netflix do. They make you log onto the main device to get an access code to put in your mobile devices. They used to try to limit how many devices you could watch on at one point, now they've embraced the fact that it's going to happen, and even let you control which device you send the show to.

 

With the nature of the web, it's very hard to tell if someone is logging into your site with stolen credentials.

Link to comment
Share on other sites

Sorry, what about SSL? is it hard to implement?

Not really, you just have to buy a certificate from some authority and then configure your server to use it. If your hosting your site through a company you'd give them the certificate and they will set it up for you. If you're doing it yourself you need a make a few small changes to Apache's configuration file. There are many guides on how to do that.
Link to comment
Share on other sites

If you're dealing with sensitive personal data, such as real names and addresses, then SSL is worth it. If you're dealing with financial data, especially things like credit card numbers etc, it is required.

However, as I pointed out this will not prevent someone from hijacking the session. It will only prevent someone from listening in on the communication, while in transit between the server and the client.

 

Also, cookies are required for recognising your user across page views. That's what's storing the session ID on the client, after all. Sending the session ID as an URL parameter, on the other hand, is actually the insecure option for one very good reason: URLs get logged on just about every system that they pass through.

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.