RE: concurrent logins

Zaakiy Siddiqui <[email protected]> Wed, 19 Nov 2014 23:22:52 +0000
Newsgroups gmane.comp.security.web-applications
Message-ID <975bc58122cf4081a441290d9aeec94d@SINPR03MB330.apcprd03.prod.outlook.com>
Hi all,

I'm in favour of Arvind's Option Number 2: i.e., in my way of thinking it: =
Display to the user the Geolocation of other source IPs that have logged in=
 with the same account.

Need to ensure though that if your users are using 3rd party services to lo=
gin (common scenario is they use a feature-rich third party email provider =
which is hosted on the other side of the globe).  May need to watch out of =
false positives there - scenario you want to avoid is that user would be co=
nfronted with a message saying that they've previously logged into this web=
 app from the geolocation of an AWS datacentre.

There are plenty of services around e.g., MaxMind (I'm not linked to them b=
ut I use them) that charge something like USD$10 per 10,000 API-based geolo=
cation lookups.  This can easily be integrated into a web app or into a WAF=
. You can programmatically work out false positives like the one I mentione=
d above my not reporting AWS, Azure, Gmail IP ranges, which are publicly av=
ailable - not perfect but a better balance IMHO.=20

Zaakiy (Zak) Siddiqui



-----Original Message-----
From: [email protected] [mailto:[email protected]] On=
 Behalf Of James Wright
Sent: Thursday, November 20, 2014 1:34 AM
To: [email protected]
Subject: Re: concurrent logins

Hi Robin,

As you said, it depends a lot on what the application is for.  If it is som=
ething like email, a user may wish to access it on a computer and a smartph=
one, and stay logged into both.

If the web based system requires more security, or is limited by a license =
(100 concurrent user limit) or another resource limit, it may be useful to =
limit concurrent logins.  My thought on this is that the application should=
 allow the logging on user to choose whether or not to disconnect the alrea=
dy existing connection.  This way users can force off old and stale connect=
ions (reduced support from IT or AppDevs), and is alarming to the user if a=
n attacker forces someone off (user will most likely report the occurrence)=
.

With concurrent users, very few monitor or care about sessions other than t=
he one they are currently using.  Not allowing a user to login because of a=
nother running session is a headache for the user, and creates more support=
 tickets.


Thanks,
James

On Wed, Nov 19, 2014 at 5:30 AM, Robin Wood <[email protected]> wrote:
> What are peoples opinions on allowing concurrent logins to web apps? I=20
> 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 -=20
> 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=20
> 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
--------------------------------------