Re: concurrent logins

On 24 November 2014 at 08:03, Stephen de Vries
<[email protected]> 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 s=
tart thinking about secondary countermeasures against session hijacking its=
elf.

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-en=
ter the password so that that specific request is authenticated.

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

Robin

> regards,
>
>
> =E2=80=94
> 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
--------------------------------------