Assurance

["Cantor, Scott" <>]

On 3/12/14, 2:40 PM, "Josh Alexander" 
<>
 wrote:

>I think I get what both of you are saying - but to Tom¹s previous question
>- what if you could leverage social engineering and
>convince/hassle/provoke a user to grant access (press ALLOW) for
>un-authentic requests?

That's not up to the user, it's up to the server to screw up. You can
certainly convince a user to supply information to an attacker, but you
can't get them to volunteer their private key unless you just ask for it
(and needless to say they wouldn't know it or be able to give it to you in
the way you mean).

And you can't, as an attacker, authenticate the client and turn around and
be that client to a server, you don't have the private key. That's what we
mean by non-phishable.

> 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.

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".

-- Scott