Re: concurrent logins

[Robin Wood <robin@digi.ninja>]

On 19 November 2014 16:41, Seth Art <sethsec () gmail com> wrote:
> 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.

I think this is going to be my main stance, suggest it, give reasons
for and against and let the business make the decsions.

I think there is a stronger argument for it when you've been able to
demonstrate session hijacking or some type of login failure during the
test but that also warrants discussions over the general login and
session handling.

Robin

> Seth
>
>
> On Wed, Nov 19, 2014 at 5:30 AM, Robin Wood <robin@digi.ninja> 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
--------------------------------------