There are a few ways in which a constant key stored on a token, such as Yubikey, can be compromised. One is the obvious key-logger. A key-logger will capture the password “typed” by the token just as easily as it would capture a password entered by the user. Another threat occurs when the token is captured by an opponent, without it being noticed (i.e., it is “borrowed”.) Such an opponent will be able to cause the token to emit the constant key and capture it. This process takes five seconds and can take place whenever you leave your token unattended for a minute. Once the constant key is known to the opponent, the value of the token against this opponent becomes zero, and all security you have left is the additional part of the key which you enter yourself from memory.

This particular threat was elegantly mitigated in one of the products that were programmed to use Yubikey: Password Safe. Password Safe is an open source password manager, maintained today by Rony Shapiro, a skillful security engineer who I know in person. He devised a way to make Password Safe able to use a Yubikey with a key that, while being constant (there is no way around this with local encryption), is resistant against the threat of token borrowing.

The borrower threat can be mitigated by sending a password to the token as a challenge, and using the response as a key.

The concept is simple: instead of using the constant key that the token emits, the challenge-response mechanism is triggered instead. The challenge that is sent to the Yubikey derives from the password, which the user remembers and enters. In return, the Yubikey emits a response which is a function of this challenge and the internal key that never goes out. This response is used for local encryption; of the passwords database, in the case of Password Safe. Since the challenge is constant, so is the response. Therefore, a key-logger will still be able to capture a usable key. This is inevitable; local encryption implies that the encryption key is available on the workstation, making it visible to a privileged attacker. However, someone who merely takes your token away, without knowing the password you enter, has no way of triggering the Yubikey to create and emit the key used for encryption.

Of course, like most other security measures, this improvement comes at a cost. The cost is in resilience, in case the token is lost of broken. When using a simple constant key, you can always keep a copy of this same constant key printed on paper and locked in a safe. If you lose the token, you can always type the very same constant key manually. By the Password Safe model, the key cannot be captured outside Password Safe, and thus you cannot create a backup, other than by introducing a second Yubikey. When using tokens for remote authentication, there are no data resilience issues. If your key is lost, you call the server manager to get it revoked, and to enroll a new one for you instead. The data is plain on the server, and is not at risk of being lost with your token. When your data is encrypted with a key locked in the Yubikey, when the Yubikey is lost, so is your data, unless you have a second Yubikey.

In my opinion, this is a worthy trade-off. Encrypt the data with the token, and make sure you keep good backups, extracted on a trustworthy platform. It is not the most convenient, but the risk of someone gaining occasional access to your token is way too probable to be ignored.