Web Application Security
concurrent logins Nov 19 2014 10:30AM
Robin Wood (robin digi ninja) (6 replies)
Re: concurrent logins Nov 19 2014 04:43PM
Seth Art (sethsec 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 <robin (at) digi (dot) ninj [email concealed]a> 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
--------------------------------------

[ reply ]
Re: concurrent logins Nov 19 2014 02:34PM
James Wright (jamfwright gmail com) (1 replies)
RE: concurrent logins Nov 19 2014 11:22PM
Zaakiy Siddiqui (zaakiy nticon com au)
Re: concurrent logins Nov 19 2014 02:33PM
Matt Konda (mkonda jemurai com)
Re: concurrent logins Nov 19 2014 02:32PM
Arvind (arvind doraiswamy gmail com)
Re: concurrent logins Nov 19 2014 02:13PM
DavidMeans833 (at) air-watch (dot) com [email concealed] (DavidMeans833 air-watch com)
Re: concurrent logins Nov 19 2014 01:17PM
Irene Abezgauz (irene abezgauz gmail com) (1 replies)
RE: concurrent logins Nov 21 2014 08:58AM
Nigel Ball (Nigel K Ball dsl pipex com) (1 replies)
AW: concurrent logins Nov 21 2014 10:20AM
Wolfgang Abbas (wolfgang abbas de)


 

Privacy Statement
Copyright 2010, SecurityFocus