Overview
This is just a brief outline of a man-in-the-middle attack on a YubiKey. It's already a widely known attack. [Edit 24th October 2012: As pointed out by Simon Josefsson this attack is valid for almost any OTP type device]
Participants
- Alice, the valid user
- Bob the Bank, the person/service Alice wants to prove her identity to.
- Mallory the attacker
Attack
Mallory goes to the Bank's website and copies their design to a new place. He then puts up the credible-looking-but-actually-malicious website. As an aside, The HTML5 fullscreen API actually makes this quite easy, as you could make something that looks a lot like the user's browser, complete with green padlock to signify a good SSL connection and the bank's URL.
He then convinces Alice to visit the bad website and enter her credentials. When she enters her username, password and YubiKey OTP, Mallory uses them to empty Alice's account and then redirects Alice to the bank home page, making it seem like she's entered a bad password.
Alternatively, Mallory calls Alice and claims to be Bob. Alice believes him and hands over credentials, including an OTP. Mallory immediately uses it to interfere with Alice's account.
This actually becomes even more problematic, as Mallory could then potentially add his own YubiKey to Alice's account as an authorised user of Alice's account and remove Alice's access. Mallory can now access Alice's account at will.
Defense
Even with the hardening technique mentioned in the clarification of my previous YubiKey post, this technique still works!
The "correct" defense is for the YubiKey to refuse to give out an OTP except to someone who can prove their identity to the YubiKey, e.g. by passing a signed message to the YubiKey. However, this massively decreases the usability of the system and increases the cost to deploy, as it will require system-specific drivers.
The softer version of this is for people to not reveal their OTPs until they have been invalidated by usage.
First so that it is clear, this is not an active that is specific to the YubiKey, it applies to all password and OTP-based systems regardless of technology, as far as I can see.
ReplyDeleteHowever, there are some other defenses that you could take, by using the timing information stored in a YubiKey OTP. There is a prototype of some ideas at this URL: http://timedelta.yubico.com/ With a scheme like that, you can mitigate attackers that harvest OTPs from a particular device, and ramp up the cost for the attacker.
/Simon
I agree, and I will edit the post to the effect that this kind of attack is valid against almost any OTP system.
ReplyDeleteIf they timestamps must be within ~4 seconds of one another, then yes, this mitigates a phone-call based phising attempt, as reading out 3 OTPs over the phone in <4 is probably going to be difficult. However, it still doesn't mitigate the attack outlined in my post, sadly :-/
The Ubikey needs a 0-9 keypad to accept a user 4 digit pin code.
ReplyDeleteIt should send the long password output on the 4th key press - if correct PIN code then valid password, if incorrect password then a random incorrect password is sent (so you cannot tell it is a duff password).
A cheaper variation could be to use the single button already on the ubikey but to only output the pwd after a certain sequence of taps (e.g. 1 1 1 pause 1 1 pause 1 1 1 1 pause 1 1 1 1).