7

One of the reasons we opt to use 2-factor authentication is to minimize the impact of keyloggers. The theory is that even if an attacker is able to observe the user type in the token numbers, they wouldn't be able to use this information, since the nature of one-time passwords prevent their reuse. However, if an attacker is able to observe the keypresses in real time, there is always going to be a small period of time between when the digits from the token are typed in, and when the "Enter" button is pressed. An attack tool can be easily scripted to take advantage of this lag to authenticate on behalf of the attacker.

I know that yubikeys submit "Enter" as part of the string of characters they send, but how to solve this for RSA and Google Authenticator tokens? Is there a solution?

Shelvacu
  • 2,333
  • 4
  • 16
  • 29
mricon
  • 6,238
  • 22
  • 27

1 Answers1

7

Not really, at that point you are dealing with a compromised client and pretty much all bets are off. The best you can do is ensure the user is aware of the failure which will (hopefully) result in them asking questions or trying again. When a user connects the old user should be booted. This should make a legit user aware of the problem even if they don't understand it.

Also, if a client is so compromised, there is likely no need for a race condition, the attacker could simply use the compromised client that the user is legitimately using as the launch point for their nefarious deeds. This wouldn't throw off any alarms since both the good and the bad are coming from the same client.

AJ Henderson
  • 41,816
  • 5
  • 63
  • 110
  • 1
    Or just steal the cookies, if you have enough access to the client, secure flag or the fact it was sent over SSL isn't going to help. – ewanm89 Jan 05 '13 at 10:16