Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

We are currently developing a web application. The developers have allowed multiple login. e.g an user can log-in to multiple computers at the same time. They are quoting Gmail account as an example of allowing multiple access.

We have secured our web application similar to here.

Does allowing multiple login at different computers/browsers increase vulnerability to hacks?If yes, how can I explain this to the developers?

share|improve this question
2  
vulnerable to what if i may ask? –  user1451340 Apr 26 '13 at 7:19
1  
Keep in mind that gmail also tracks these logins and the user can view this history at any time, which includes Access Type, Location (IP address) and Date/Time stamps. The user also has the ability to sign out all other sessions. The user has the option to be alerted when unusual login activity is occurring. Does your application provide this functionality? Because if not, than they can't use gmail as an example to justify multiple multiple logins. –  k1DBLITZ Apr 26 '13 at 16:20

4 Answers 4

up vote 3 down vote accepted

There is a good reason for preventing concurrent connections - if they are not needed by your users.

A good rule of thumb is to not allow more functionality than that which is needed. If your users are never going to connect more than one simultaneous session, disallowing it would reduce the risk of attack (as an attacker would not be able to conduct their attack while the user was logged in.)

If, however, your users may expect to use multiple sessions, then you'll have to have this functionality.

Really, this question comes down to a functionality issue - google know their users may need to connect from multiple machines/locations/browsers at the same time, so they just notify of other sessions, rather than prohibit them.

share|improve this answer
1  
I disagree. There are tree ways to handle this A- New sessions will invalidate the old ones. The attacker can override the user's session. B- Prevent a new login unless the user logs out out from the last session. "Oh, I logged in from home last night, now I cannot use the website on my mobile. C- Killing the session after some time. "Remember me" option doesn't make sense anymore. I believe in this matter the default should be allow, unless your service doesn't need multiple login (like a bank). –  Adnan Apr 26 '13 at 15:20
    
All three of those points are good - they don't disagree with what I said at all. My favourite is that a new login invalidates the old one - this means if an attacker tries to do something it can be immediately detected. –  Rory Alsop Apr 26 '13 at 16:53
    
@adnan I think stackexchange does it quite nicely. may be they keep a flag on the server side and notify the user if he is already logged in from some other device. –  Shurmajee Apr 28 '13 at 16:31

I think all the answers given so far are all valid. However I'm not sure I agree completely. Take this site for example. I can have multiple 'sessions' open and logged in on stackexchange.com, does that make security.stackexchange.com less secure? I think that the merits of that are debatable, and there are pro's and cons to the argument. Although I would say that any increase in security risk from allowing it is negligible.

I think that the issue of multiple logins dependant of scenario, is less a question of security and more a question of process. It may make sense to disallow multiple logins due to business process for example licencing. But in other scenarios it may make sense for example increase in usability. Its up to you as the architect to decide if the increase in risk is worth any perceived benefits, or increase in work to disable multiple logins.

share|improve this answer

I don't think allowing multiple user to connect is vulnerable to attack. If Gmail allows this, I'm sure they thought about the potentials risks ;)

Now, that doesn't mean your application isn't vulnerable, but it will be more based on how you developped the login process (https, database hashed password, etc).

Since you mention that you have secured your application like indicated on that post, you have greatly reduced the risk (I can't say it's 100% secure, nothing is).

Now, you can add the same feature as Google Mail : Listing all the current connected session for the user. Doing so, if an user account is hacked and accessed by someplace else, it will be possible to see it, the IP behind it, etc.

It won't be more secured, but it will provide some relief for your users.

share|improve this answer
    
For the people that did a -1, I would appreciate an explanation. So far, I only feel like a "I don't like you, here's a -1 for you". Very unproductive... –  Cyril N. Apr 26 '13 at 13:12
    
Google allows multiple logins because they are tracking multiple factors in the backend, such as country, IP, etc. They also are likely mapping your patterns, have options for multi-factor authentication, and have a lot of monitoring. My guess is the downvotes resulted from saying that google does it so it must be okay. The risks and ability to mitigate risks will differ from org to org. –  Eric G Apr 26 '13 at 17:39
    
@CyrilN. First of all, I didn't downvote this. Voters don't have to explain their vote, whether it's +1 or -1. It's very childish to accuse downvoters of "not liking you". Actually, nobody here is supposed to like you; it's the Internet. –  Adnan Apr 26 '13 at 18:14
    
@Adnan I didn't accused you of downvoting me ;) The thing is, I'm really open to -1 because it mean I'll learn something. But then, no comment. So, there is apprently a mistake in my answer (hence the -1), but no explanation of this reason. The result is that I know something is wrong with what I said, but I can't know why. That's why I don't like downvote without comment. –  Cyril N. Apr 26 '13 at 18:21
1  
@CyrilN I agree with you, people who down vote should have to provide some feedback. There does tend to be some level of people rise to a certain level here and then start running around down voting things they don't like or disagree with. Bottom line on security is that there are a lot of different perspectives. What yours is might be totally different from mine. I would hope this forum would want all of them put out there for us all to learn from. –  Tek Tengu Apr 27 '13 at 9:49

I think the issue and concern really is defined by the data and systems in question. If the each login, allows the mutation (changing) of shared data, or change in shared systems, then having multiple logins by the same user is a problem.

In the case of gmail, the data in question is individual and not shared so this is never the case. If I change my gmail in one login, then I am only shooting myself in the foot.

Also from a security standpoint there are some concerns that I would raise/consider:

  1. Anytime you allow multiple concurrent logins, you are essentially saying that you have unsecured connections to your system. If the computer that system is running on is not properly secured then that "portal" is open and free to someone who is not the proper user abusing the login - so you have lost the traceability and repudiation of your system.

  2. Of course any active page (unless it is pure html) is going to represent a "portal" of potential exploits that if an aggressor has access to attack may then exploit for further escalation beyond the logged in user's authority. Or even worse may create a portal to attack the systems the application and its data is hosted on and subvert all controls and gain full access to the "crown jewels" so to speak.

  3. Finally never believe your own BS, you have not secured your application. You have done your best to secure your application to the best of your knowledge at that point in time - otherwise 0day attacks would not exist. So never believe your application is "secured" and thus, you can do something that looks nominal like you are proposing. No offense intended here, but it is the truth. Always be paranoid about security.

share|improve this answer
    
just out of interest can you clarify what you mean by 'you are essentially saying that you have unsecured connections to your system'. in point 1. –  Nicholas King Apr 26 '13 at 12:17
    
What I am saying is that if the real user is not sitting at the interface they logged in, then it is essentially unsecured - it is not under their auspices and direct control as it should be. –  Tek Tengu Apr 26 '13 at 13:15
    
I think I get what you are saying although I fall out with the use of the word 'secured'. The connection to an interface can be secured through the use of HTTPS. If hacker Bob connects through another session at another computer it does not mean I have insecure connections to my system. Although you are right that if two people can log in at the same time in different geolocation under one login then the session may not be under the auspices of the original user. –  Nicholas King Apr 26 '13 at 13:21
    
I would argue the multiple mutations issue is not as big a threat, take something like Google docs where two users can edit the same open file. The server processes things in the order received, can be problematic, but not neccesarily a security concern –  Eric G Apr 26 '13 at 17:42
    
@EricG Actually you pose a situation that is a security concern. It is a security concern on two fronts. First, the unordered mutations by a non-controlled user login, could be a path for an exploit to enter a system under a known user login - when it is not that user. Secondly, in the terrorism world, what you describe is being used as a covert channel of communication. So both are security concerns. BTW, you might want to check the spelling of Chicago on your profile. Someone may have edited it from another login while you were logged in somewhere else :). –  Tek Tengu Apr 27 '13 at 9:46

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.