Skip to Content.
Sympa Menu

assurance - Re: [Assurance] can two-factor be hacked ?

Subject: Assurance

List archive

Re: [Assurance] can two-factor be hacked ?


Chronological Thread 
  • From: Tom Scavo <>
  • To:
  • Subject: Re: [Assurance] can two-factor be hacked ?
  • Date: Wed, 12 Mar 2014 16:03:28 -0400

On Wed, Mar 12, 2014 at 2:57 PM, Cantor, Scott
<>
wrote:
> On 3/12/14, 2:40 PM, "Josh Alexander"
> <>
> wrote:
>
>> Additionally, so far the conversation has been
>>steered toward MiTM attack vectors against MFA, but what about MiTB and
>>various endpoint attacks that happen post session authentication - what
>>are your thoughts as to if/how MFA can defend against these attacks behind
>>session auth?
>
> This is obviously off in a different direction...
>
> MiTB is basically a total break, and given a poor enough browser
> implementation or bug, you could even conceivable steal a key stored
> locally on the machine in the process. A MiTB is simply saying there's
> malware on the machine, e.g. the various Java applet sandbox bugs, etc.
>
> But I think you're maybe asking about what kind of session strength you
> have after logging in, and the answer there is "lousy". Without a private
> key, you have cookies and that's it. With a client cert, you can do
> better, but it's extremely common for people to build apps that leverage
> client certs for login, but then end up with cookie-based sessions
> afterward because that's the assumption the frameworks all make, since
> client certs are rare.
>
> What you want is a session at least bound to the client cert in some way,
> or the SSL session, but you rarely get that, much like you often see
> people punt on binding a cookie to an IP address because of NAT.
>
> But a MitB can basically own any session, it's the endpoint of the session.

Very useful, Scott. Thank you for that.

> And no, I see no real way MFA can do much here (speaking of MFA as
> distinct from client certs, I don't consider them the same category). What
> it can do is add a channel to authenticate a transaction, right? Which was
> Bruce Schneier's point Tom was referring to. But in a sense that's saying
> "you can't trust the session, so don't rely on it, login again every time
> it matters".

I totally agree. One example I've heard is the bank example that
Schneier alludes to. At the point the user tries to make a money
transfer, require confirmation on an independent channel.

Tom



Archive powered by MHonArc 2.6.16.

Top of Page