Re: concurrent logins

[Robin Wood <robin@digi.ninja>]

On 24 November 2014 at 08:03, Stephen de Vries
<stephen () continuumsecurity net> wrote:
> > 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.
>
>
> Session hijacking is only possible after some other vulnerability in the site is exploited, e.g. XSS, or lack of 
> HTTPS.  So I would first focus the effort into countermeasures for those vulnerabilities and only afterwards start 
> thinking about secondary countermeasures against session hijacking itself.

Agreed that defending against things like XSS is important but having
a policy on concurrent logins from the start of development is part of
good defence in depth and is something that you can write provable
tests for as opposed to XSS which is harder to do definitive testing
for without getting a tester in.

> A countermeasure not yet mentioned is to authenticate specific high risk requests with a password, or PIN.  E.g. when 
> initiating a transaction like funds transfer/payment/password change, you could require the user to re-enter the 
> password so that that specific request is authenticated.

That is a good measure that helps protect high value areas.

Robin

> regards,
>
>
> —
> Stephen de Vries
> CTO Continuum Security
> Mobile: +34 616 33 81 38
> UK: +44 20 3137 0944
> @stephendv
>
>
>
>
> 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
--------------------------------------