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