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: Dana Watanabe <>
  • To:
  • Subject: Re: [Assurance] can two-factor be hacked ?
  • Date: Tue, 11 Mar 2014 08:35:05 -0700

On Tue, Mar 11, 2014 at 7:34 AM, Cantor, Scott <> wrote:
On 3/11/14, 3:20 AM, "Jones, Mark B" <> wrote:
>
>As far as the original question.  It seems to me that MFA is a good
>defense.

Then I think you misunderstand the question, it's the exact scenario where
typical OTP approaches to MFA do not solve the problem. A MITM attack
against all legs can simply steal and play the OTP to obtain a session.
Normally it's done innocently as in this case, but it can be done as an
attack.

Part of the problem, it seem to me, is that while we call it multi-factor, there's really only one factor:  Information.

Both the "something i have" and the "something i know" are transmitted the same way.  As long as all factors are turned into information that is passed remotely, it would seem to me that there would always be a susceptibility to a MITM issue.

Seeing as this is an IT issue, i'm not sure of the way around that aside from pre-negotiation of keys with every client. (Compared to, say, having a key that fits a lock* and having to type in a code.  Not so ideal for needing to make a change in the payroll system. ... and chances are nowadays, the "key" would end up being an RFID card that still transmits data).  

I think David (among others) points to the trickier, but more useful, question:  How do we train users?

Certificate and Browser folks came up with the nifty EV / Green Bar standard, which is an interesting try.  It is probably least effective for people most susceptible to phishing.   And the Green Bar doesn't seem to be on any of the browsers on my phone. And, of course, if we just got users to look at the URL in the first place, we'd probably catch >90% of the issue anyway.

I'm not sure how to train users, but one thing that doesn't help is having it be valid for users to use the same username/password in multiple login screen.

Which goes to Eric's point:  Here, we have a hard time getting a policy about use of the SSO.   It's hard to quantify the "the more different places a user types in the same username and password, the more likely they are to be confused by a phishing attempt" notion versus "but it's 'hard' to get this app to work with the SSO."  One's a nebulous expense of the Security Team's time (and whatever folks need to clean up the mess made, and the PR for the data breach, etc) and the other is often a more seen as concrete estimation of work time.



(*Yes, a key in a lock is really just transmitting the information of where it expects the pins to be, but the transmission is usually a very short distance and it's much trickier to do a MITM job on that.)




Archive powered by MHonArc 2.6.16.

Top of Page