Assurance

[David Walker <>]

Actually, that's a good point.  The reason that Duo doesn't help in
Steven's scenario is that it's out of band from the browser session. 
The screen-scraping proxy (man in the middle) handles the password, and
then the real application asks Duo for confirmation without involving
the proxy, so the mutual authentication doesn't see the browser
session's man in the middle.

FIDO, on the other hand, is in-band, so the proxy would have to fake the
mutual authentication somehow.  I don't think that's possible, but I'm
certainly willing to have someone with greater understanding than I show
me wrong.

David


On 04/17/2014 01:40 PM, Tom Scavo wrote:
> On Thu, Apr 17, 2014 at 4:06 PM, David Walker 
> <>
>  wrote:
>> I was just reading the FIDO Alliance's U2F overview
>> (https://fidoalliance.org/specs/fido-u2f-overview-v1.0-rd-20140209.pdf),
>> and I think they have a solution to this issue.  They use public key
>> cryptography, though not PKI, for mutual authentication of the service
>> and the token, which (I think) should defeat this kind of
>> man-in-the-middle vulnerability.
> Duo Push uses public key crypto as well:
>
> https://www.duosecurity.com/blog/heartbleed-defense-in-depth-part-2
>
> but that still doesn't prevent a MiTM (as discussed earlier in the
> thread). Doesn't U2F require a button push by the user? If so, then
> how does it avoid this problem?
>
> Tom