Two-Factor Authentication: Demand Bi-Directional

BSides Las Vegas 2017

Please use keyboard arrows to navigate.


  • two-factor does:
    • Protect your account from compromise in the event of a password breach

  • two-factor does not:
    • Protect you from being phished
    • Protect you from confirming something out-of-band

How do event-based OTPs work?

Counter based One-Time-Pads

e.g. HOTP - counter based

$Truncate(HMAC(secret, counter))$

Time based One-Time-Pads

$Truncate(HMAC(secret,\lfloor{(\frac{t_{Now} - t_{Init}}{t_{Period}})}\rfloor))$

What is the problem?

This is an example of a homoglyph attack, but DNS hijack would be another example

Did we encounter this before?

Yes: Challenge-Response Authentication Mechanism (CRAM-MD5)

Demo 1 : 2FA phishing

Desired features of the solution.

  • Prevents an attacker from stealing a user's credentials
    • DNS hijack attacks
    • Homoglyph hostname attacks
  • Protects static inputs with variable inputs
  • Technology agnostic
  • Adds no more friction to the current user experience

A Proposed Solution

RFC 4226 ~ December 2005


$Truncate(HMAC(secret,\lfloor{(\frac{t_{Now} - t_{Init}}{t_{Period}})}\rfloor || ipBlock))$

Demo 2 :
Veerless resisting a homoglyph attack

What just happened there?


  • Credential Phishing
  • Corrects the User Trust Model


  • Client needs access to DNS resolution API
  • Compromises between usability and secure isolation
  • User Adoption
    • Password only systems might be a problem

Future Directions

Extending Free-OTP

Push based?