Re: concurrent logins

[Robin Wood <robin@digi.ninja>]

On 19 November 2014 14:27, Aaron Sanders <malmoose37 () gmail com> wrote:
> Just thinking out loud (still haven't had coffee yet) but what about second
> factor? Is that in scope for this question? I would think you can allow all
> the concurrent sessions a user wants as long as all of them were validated
> with second factor.  If an adversary can compromise the second factor source
> then there are bigger issues. Though I suppose a session hijack is still
> possible after the dual auth. To cover that case, what about source ip
> tracking? Session tokens don't normally travel across systems so if the ip
> changes then user needs to re-auth.

The reason I was thinking about this is the thing I was reading was
suggesting to prevent session hijacking that concurrent logins should
not be allowed, 2FA stops actual logins but not hijacks.

Tying sessions to source IP can be a problem when users are on
networks that can switch egress IP.

Robin


> -Aaron
>
> On Nov 19, 2014 7:00 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
--------------------------------------