What is the risk and mitigation of accidentally typing a YubiKey password in an open forum?

Question

I have a YubiKey in my laptop (for testing) and accidentally broadcast my YubiKey password out to the Internet. Since this is only a test key, and has no access to anything of value, here are some sample OTP keys:

ccccccbhknbgunfejcduuficrglhbckgbbugjegrbbbj

ccccccbhknbgncbjurrufidrvjvjnbglduvnjtccjhif

My understanding is that in the default configuration, the leading characters is an identifier (unique ID) of sorts :ccccccbhknbg. I'm unclear if this is an encoded value, or if it's a raw ASCII value.

• What is the risk of sending these passwords out on the internet? Was any privacy lost?

• Does it matter if it's connected to the YubiKey cloud, or if it's part of a stand-alone configuration?

• How can I recover from this? Can I regenerate any identifiers? How can I invalidate the passwords?

Answer 1

There are some explanations on what YubiKey does here. Basically, the password which the YubiKey "types" (from the point of view of the computer, it is a keyboard) can be either a static password, or a one-time password. If it is a static password, then you just revealed it, and it is time to be very sorry (and promptly change that password).

The one-time passwords, what YubiKey produces follows HOTP. The cryptography in HOTP is such that it is not computationally feasible to recompute the "master secret" from one or several one-time passwords produced with HOTP. Moreover, each password is internally computed from a counter. The YubiKey and the server both maintain the same counter, and the server allows for some limited lack of synchronization. Namely, when the server's current counter has value n and receives a password as authentication attempt, it will internally generate the passwords for values n+1, n+2,... up to, say, n+100 (that's configurable). If a match is found with (say) password n+17, then access is granted and the server's counter is set to n+17; otherwise, connection is rejected and the server's counter is not changed.

Therefore, what you inadvertently published "on the Internet" is a password which will grant access to the corresponding server, until your own next authentication on that server, because that authentication will update the server's counter to a further counter value. In a way, using OTP with counter value k invalidates all OTP values with values j < k. Which leads to the following recovery procedure: if you published an OTP value, quickly connect to the server so as to invalidate that published value. Afterwards, you can just ignore it; once invalidated, it is harmless.

(Note: if you repeatedly generate a lot of "blank" passwords with your key without authenticating to the server, your YubiKey may go out of synch with that of the server -- the key using counter values way beyond what the server would currently accept. Don't let your 3-year-old play with your YubiKey ! In a similar situation, for infrared car keys, counter synchronization is forced through RFID when you start the engine.)

Answer 2

The YubiKey supports the Yuibco OTP, which is the long OTP generated.The YubiKey One Time Password (OTP) is a 44-character, one use, secure, 128-bit encrypted Public ID and Password, near impossible to spoof.

The OTP is comprised of two major parts; the first 12 characters remain constant and represent the Public ID of the YubiKey token itself.

The remaining 32 characters make up a unique Passcode for each OTP generated. The Passcode is generated from a multitude of random sources, including counters for both YubiKey sessions and OTPs generated. When a YubiKey is validated, the Session and OTP Counter values are compared to last values submitted. If the counters are less then the previously used values the OTP is rejected. Copying an OTP will not allow another user to spoof a YubiKey – the counter value will allow the validation server to know which OTPs have already been used.

You can read more about the YubiKey OTP here

Answer 3

The Yubikey OTP token string is generated by encoding the hexstring of the raw data into a special subset of lowercase alpha (latin) characters. For instance, c happens to be the encoding of hexadecimal nibble (digit) 0.

By default, that first 12 characters (6 bytes) of the OTP token from the "vanilla" Yubikey, with the default configuration and keys, is the serial number. So you have just leaked it: 14***93, isn't it?

The rest is AES-128 encrypted data (counter, random nonce, ..) so I would not be worried.

The encoding is called Yubico modhex and it is designed to prevent ambiguity of keyboard scancodes on different keyboard layouts (e.g. QWERTY vs AZERTY):

0123456789abcdef
cbdefghijklnrtuv

There's also online demo and converter.

Answer 4

You're fine. You only lost a "username" type of identifier.

Thomas isn't quite correct with regards to the part about the server generating 100 passwords to check.

The second part, the "OTP" is encrypted. The server decrypts the OTP using it's AES key. The decrypted content has the counter. If the counter is equal to or less than the last counter the server authenticated, then it is a replay attack.

If you want to create a new AES key you can, then you can upload it to yubico, but they say that it does not have the same uptime guarantee. However, just spewing out a few OTP's won't compromise you.