RE: concurrent logins

Hi,

Not really another option but something that could be added to the =
options already listed is automatically logging out inactive sessions. =
How long you wait (minutes / hours / days) before deciding a session is =
inactive and logging it out would depend on the type of application and =
security concerns.

Nigel Ball
Cambridgeshire UK

-----Original Message-----
From: [email protected] [mailto:[email protected]] =
On Behalf Of Irene Abezgauz
Sent: 19 November 2014 13:17
To: Robin Wood
Cc: [email protected]
Subject: Re: concurrent logins

Hi,

some thoughts, no particular order.

People use multiple devices, so disallowing concurrent logins is not an =
option for most sites.

This obviously depends on functionality. Social communication sites do =
not have the same needs as banking apps or =
nuclear-launch-management-interface
etc.


looking at your 1-6:
1. Allow concurrent logins <-- most sites 2. Allow concurrent logins but =
report that someone else is logged it - like Gmail does <-- many sites. =
this is not bad especially the google way such as putting a bigger, more =
noticeable line if they see a specific problem (for example deviation =
from behavioral patterns) 3. Don't allow them and kick out any logged in =
user when a new one logs in
<-- few sites. often thick clients etc. In many cases this is due to =
application functionality more than security needs ;) 4. Don't allow =
them and lock out all new logins till old ones have logged out <-- that =
can cause functionality problems, such as the admin that locked a bunch =
of files and interfaces and then went on vacation.
5. Give a warning popup when logging in to say the account is in use =
elsewhere as well <-- I like this one, but it's not a one-size-fits-all =
solution. nobody wants this annoyance on their social network site.
6. Allow but report back to an admin or log tracker or similar <-- =
depends on the site. on large traffic sites you can't really have =
multiple logins reporting to admin.


if to break this into a very rough site-type classification:

1. Retail - no reason not to allow multiple connections. users want to =
be able to log in from their tablet, but also from their phone and/or =
laptop.
You can require additional authentication (password for example) before =
important operations. Concurrency - not necessarily a problem.
2. Banking/similar - Although you don't really have to allow concurrent =
connections, most sites won't block it. Again, you need to look at the =
risk. A lot of the controls are done on different levels - such as =
monitoring the standard 'behavior' patterns of a user and then checking =
whether the new login matches that and if needed utilizing a secondary =
security mechanism 3. Social sites (FB, linkedin, or
whatever-young-people-are-using-these-days) - again - concurrent logins =
are usually needed. FB and similar send you an email saying 'new device' =
and you can also configure to disable.
4. sensitive interfaces - usually not a lot of users. be the annoying =
security person and play with settings as much as you want :)


the bigger question here is - what are you trying to achieve?

disabling concurrent logins because security? I'm not sure that's the =
way to go for most apps. notifying the user - yes you can do that, most =
of them won't know what to do with it.

2FA (not bullet proof, but efficient in most scenarios these days), =
notifications of new device, extra security layer if behavior is =
non-standard (different country in a short time, etc) is probably better =
than just 'don't do concurrent logins'.

Irene

On Wed, Nov 19, 2014 at 12:30 PM, 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=20
> etc - but do the protections from it add more problems that allowing=20
> 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=20
> 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=20
> to say the account is in use elsewhere as well 6. Allow but report=20
> 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=20
> in Gmail which says where else the account is logged in from, I don't=20
> 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=20
> 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=20
> 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=20
> 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=20
> 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!=20
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
--------------------------------------