WebApp Sec mailing list archives
Re: concurrent logins
From: Robin Wood <robin@digi.ninja>
Date: Wed, 19 Nov 2014 14:19:20 +0000
That is my number 3 but giving a warning when logging them out. Could still result in a DoS and you'd have to either write very good copy on the warning or train users what to do when that happens as I reckon most would just click OK and then log back in again. Robin On 19 November 2014 14:14, Rogan Dawes <rogan () dawes za net> wrote:
Think you missed: 7. Log the new session in, warn that another session was active, terminate the old session. Seems to have all the desired properties. o Can't deny access to the account to someone with legit credentials. o Prevent concurrent sessions o Inform of concurrent sessions o If the attacker logs in second, the legit user is informed that another session was created, and that is the reason they were kicked out. This should be an alarm bell, if they had not tried to authenticate at the time. Rogan On 19 Nov 2014 12:30, "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 --------------------------------------
Current thread:
- concurrent logins Robin Wood (Nov 19)
- 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)
- <Possible follow-ups>
- RE: concurrent logins Martin O'Neal (Nov 19)