4

I've just been reading some posts about FIDO support (or the lack thereof) in password managers and want to check whether my understanding is correct.

My understanding of FIDO (v1) is that the device contains a secret that it will never let out of the device, and all it has to support is digital signatures based on keypairs derived from this secret. Roughly, when you log in to example.com, the device computes a site-specific keypair based on some KDF(secret, "example.com") and then signs the server's challenge with that.

In other words, a FIDO token does not have to function as a source of secret keying material, which means that it makes no sense to use it with an offline / standalone password manager. After all, you want the password database to be encrypted with a key that's not stored in or next to the database itself, which is why you set a master password from which you derive the key. A FIDO device lets you prove possession of a key, but as it's (for practical purposes) "zero knowledge" that's no use for unlocking an encrypted database.

(In contrast, yubikeys that offer other modes as well as FIDO do make sense together with password managers precisely because they can hold your key and export it when you need to open the password manager.)

So for example pwsafe+yubikey exists, but pwsafe+generic FIDO isn't likely to happen soon. (I haven't checked the FIDO2 standard in detail yet, maybe that has a mode for this.)

But then you read things like keeper password manager enables FIDO support. How is this supposed to work - is the secret stored in some form on their servers, which is only released to you when you successfully authenticate with FIDO?

schroeder
  • 123,438
  • 55
  • 284
  • 319

1 Answers1

1

Sorry to burst your bubble, but here's actually only one mode of Yubikey that REALLY makes sense for PW managers in a complete sense and that is the Smartcard mode, but there is basically no passowrd manager that actually uses it.

Online Password Managers often go with Yubi-OTP due to it's sheer compatibility only requiring a USB slot and basic keyboard drivers (and a keyboard layout that doesnt screw modhex), but some are also going to U2F simply because

  1. It's more secure to there not being any shared secrets (Yubi-OTP uses shared secrets with Yubico when used in their cloud setup or with the provider in a custom setup)

  2. you cannot identify the specific key used. you know, the first 12 or so characters of a Yubi-OTP are the serial number in modhex (factory default) or something the user chose when customizing it).

    this allows the backend to look up the correct keys to decrypt the actual OTP data, for U2F on the other hand, while you generally are not wrong about the KDF(domain,secret) thing for generating the key, there's a LITTLE bit more to consider.

    There actually is a third value used in there. a random nonce generated at registration which is part of the "key handle" which is needed for authentication and is why even if you use single factor U2F you still need a way to know who you are authenticating (like a user name) to provide the key handles along with the challenge.

Offline Password managers often go with the HMAC road which is literally just HMAC(data, secret), depending on the details of your password manager they do it in one of 2 ways:

  1. just use the result from HMAC(some static value,secret) as part of the decryption key, which does work but is obviously bad since one capture leads to its compromise.

  2. what Keechallenge is doing: they store the secret and use that to pre-generate the next result to use in the decryption process while storing the challenge for that result in the open to obviously issue that challenge during the next open.

both methods are not ideal since seeing just one decryption breaks this for the complete lifetime of the database except maybe if a rotation (of the challenge for 1, of the secret for 2) is done every now and then.

considering how yubikeys work on PW-DBs we can basically see how U2F can work in pw databases.

  • online obviously as data valve, "you ain't getting the db unless you bring the U2F"
  • offline as snakeoil

  • offline in a similar manner to yubikey HMAC, we keep the keyhandle open to issue it and actually use the public key not as an actual public key but just as content to generate our symmetric encryption key.

    if this sounds crazy to you, let me assure you, it is crazy but it's not much different than using HMAC mode for encryption.

the only REAL way to encrypt stuff is Smartcard and/or PGP mode with rotating symmetric keys on each save, so the private key is actually needed to decrypt the database and that private key being ONLY in the yubikey.

My1
  • 394
  • 2
  • 12