Re: concurrent logins

On 19 November 2014 14:27, Aaron Sanders <[email protected]> wrote:
> Just thinking out loud (still haven't had coffee yet) but what about second
> factor? Is that in scope for this question? I would think you can allow all
> the concurrent sessions a user wants as long as all of them were validated
> with second factor.  If an adversary can compromise the second factor source
> then there are bigger issues. Though I suppose a session hijack is still
> possible after the dual auth. To cover that case, what about source ip
> tracking? Session tokens don't normally travel across systems so if the ip
> changes then user needs to re-auth.

The reason I was thinking about this is the thing I was reading was
suggesting to prevent session hijacking that concurrent logins should
not be allowed, 2FA stops actual logins but not hijacks.

Tying sessions to source IP can be a problem when users are on
networks that can switch egress IP.

Robin


> -Aaron
>
> On Nov 19, 2014 7:00 AM, "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
--------------------------------------