Re: concurrent logins

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 <[email protected]> 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" <[email protected]> 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
--------------------------------------