WebApp Sec mailing list archives
RE: concurrent logins
From: Zaakiy Siddiqui <zaakiy () nticon com au>
Date: Wed, 19 Nov 2014 23:22:52 +0000
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 login (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 confronted 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 but I use them) that charge something like USD$10 per 10,000 API-based geolocation 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 mentioned above my not reporting AWS, Azure, Gmail IP ranges, which are publicly available - not perfect but a better balance IMHO. Zaakiy (Zak) Siddiqui -----Original Message----- From: listbounce () securityfocus com [mailto:listbounce () securityfocus com] On Behalf Of James Wright Sent: Thursday, November 20, 2014 1:34 AM To: webappsec () securityfocus com Subject: Re: concurrent logins Hi Robin, As you said, it depends a lot on what the application is for. If it is something like email, a user may wish to access it on a computer and a smartphone, 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 already existing connection. This way users can force off old and stale connections (reduced support from IT or AppDevs), and is alarming to the user if an attacker forces someone off (user will most likely report the occurrence). With concurrent users, very few monitor or care about sessions other than the one they are currently using. Not allowing a user to login because of another 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 <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 --------------------------------------
Current thread:
- Re: concurrent logins, (continued)
- Re: concurrent logins Irene Abezgauz (Nov 19)
- RE: concurrent logins Nigel Ball (Nov 21)
- AW: concurrent logins Wolfgang Abbas (Nov 21)
- RE: concurrent logins Nigel Ball (Nov 21)
- Re: concurrent logins DavidMeans833 () air-watch com (Nov 19)
- Message not available
- Re: concurrent logins Robin Wood (Nov 19)
- Message not available
- Re: concurrent logins Robin Wood (Nov 21)
- Re: concurrent logins Robin Wood (Nov 19)
- Re: concurrent logins Irene Abezgauz (Nov 19)
- Re: concurrent logins Arvind (Nov 19)
- Re: concurrent logins Seth Art (Nov 19)
- Re: concurrent logins Matt Konda (Nov 19)
- Re: concurrent logins James Wright (Nov 19)
- RE: concurrent logins Zaakiy Siddiqui (Nov 19)
- Message not available
- Re: concurrent logins Robin Wood (Nov 21)
- Message not available
- Re: concurrent logins Robin Wood (Nov 21)
- Message not available
- Re: concurrent logins Robin Wood (Nov 21)
- RE: concurrent logins Martin O'Neal (Nov 19)
- Re: concurrent logins Robin Wood (Nov 19)
- Re: concurrent logins Stephen de Vries (Nov 24)
- Re: concurrent logins Robin Wood (Nov 24)