Re: concurrent logins
Seth Art <[email protected]> Wed, 19 Nov 2014 11:43:28 -0500
| Newsgroups | gmane.comp.security.web-applications |
|---|---|
| Message-ID | <CAOzeT81s0Z1uSpyJBQcQ8gTrgaoLbQ0KC2uqcx=Bu9FTt-eeaQ@mail.gmail.com> |
As a user, I love how gmail does it, and I would love to see that more. As a tester, I personally treat this one as more of a recommendation than a finding in most cases. I find this one is difficult to defend in findings review meetings, especially given the challenges you mention, and the pervasiveness of popular applications on the internet that allow concurrent logins. I think you covered the ways to handle this very well. I think it just depends on the level of security you want to achieve. I guess a slightly modified option would be to add some logic similar to what some of the 2FA solutions do now: You could require an extra step if the IP (or a combination of characteristics) of the second session has not been seen before. On Wed, Nov 19, 2014 at 5:30 AM, Robin Wood <[email protected]> wrote: > What are peoples opinions on allowing concurrent logins to web apps? I > suppose it depends on what the app is used for - forum, admin suite > etc - but do the protections from it add more problems that allowing > it? > > Solutions I can see are: > > 1. Allow concurrent logins > 2. Allow concurrent logins but report that someone else is logged it - > like Gmail does > 3. Don't allow them and kick out any logged in user when a new one logs in > 4. Don't allow them and lock out all new logins till old ones have logged out > 5. Give a warning popup when logging in to say the account is in use > elsewhere as well > 6. Allow but report back to an admin or log tracker or similar > > 1 is the default in most cases. > 2 is a good idea but really, how many people look at the little thing > in Gmail which says where else the account is logged in from, I don't > and I'm sure normal users don't even know it exists. > 3. Good but if an attacker gets creds or a reliable session hijack > then they can use them to DoS legit users by keep logging them out. > 4. Good but if an attacker gets in they can keep the account active > and so DoS the real user by never letting them log in. > 5. Maybe the best option but only works in the legit user logs in > second otherwise the attacker gets the warning and ignores it. > 6. Good one if people are watching the logs and can act on them. > > What other options are there? Can it be done in a good way that makes > if of any use? > > Robin > > > > This list is sponsored by Cenzic > -------------------------------------- > Let Us Hack You. Before Hackers Do! > It's Finally Here - The Cenzic Website HealthCheck. FREE. > Request Yours Now! > http://www.cenzic.com/2009HClaunch_Securityfocus > -------------------------------------- > This list is sponsored by Cenzic -------------------------------------- Let Us Hack You. Before Hackers Do! It's Finally Here - The Cenzic Website HealthCheck. FREE. Request Yours Now! http://www.cenzic.com/2009HClaunch_Securityfocus --------------------------------------