AW: concurrent logins

["Wolfgang Abbas" <wolfgang () abbas de>]

Good points so far!

Additionally, I think in some cases it makes sense to divide internal access to applications depending on the 
criticality of the application.

For example: I did a hardening of a cms-based extranet for a client of mine. You may log into the system with up to 
three devices (phone, tablet, pc). 
You can read articles, chat with a technician and so on.  But for certain applications you must log-in via VPN or 
access to the site from a defined IP space. 
This adds a lot of security from my perspective.

Kind regards from Germany, Wolfgang Abbas

-----Ursprüngliche Nachricht-----
Von: listbounce () securityfocus com [mailto:listbounce () securityfocus com] Im Auftrag von Nigel Ball
Gesendet: Freitag, 21. November 2014 09:58
An: 'Irene Abezgauz'; 'Robin Wood'
Cc: webappsec () securityfocus com
Betreff: 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: listbounce () securityfocus com [mailto:listbounce () securityfocus com] On Behalf Of Irene Abezgauz
Sent: 19 November 2014 13:17
To: Robin Wood
Cc: webappsec () securityfocus com
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 <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
--------------------------------------






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
--------------------------------------