zlacker

This is the exact reason I self host vault warden. I get all the convenience of syncing passkeys, but know that I am the only one with access to the back-end.

I am also slightly paranoid as a security engineer, and admit that whole heartedly.

>>amloza+(OP)
I share your paranoia and felt that passkeys were a step back as anything getting access to your browser extension memory can realistically dump both your "password" and MFA ("passkey") in one move.

I wonder if there would be a way for vaultwarden to wrap passkeys such that a hardware FIDO2 key is needed to decrypt them "per-use", and prevent software on the host from stealing a pile of passkeys that give direct access to accounts without further MFA.

Right now it feels like passkeys in the password manager is akin to storing MFA seeds and recovery keys in the same password manager...

>>g_p+H
I'm also waiting for a password manager that tightly integrates with a hardware device to protect passwords individually and in-memory.

I wrote a quick PoC using certificates to encrypt a password, with the cert private key 'stored' in the TPM, with a PIN. This is pretty easy on Windows, which exposes the TPM as a special crypto provider.

>>g_p+H
For anything that is important enough, I put passkeys on 2 separate FIDO2 key devices directly. Services that come to mind are things with recovery backdoors; like email or device backups. Unfortunately many banks and financial institutions don't support passkeys, but I'd consider using that solution there too.

>>g_p+H
Storing the passkeys on a device protected by a PIN is an option too. Example: T2F2-PIN+ Release3 by Token2 can store 300 passkeys.

>>MaKey+j6
That's a fair point, although as the PIN is validated locally, you could argue from the server perspective you gain a second (knowledge) factor, but from a local perspective it's entirely correlated with the existing stored factor (a weakness in the local device implementation can skip that PIN check and yield the result).

Perhaps this is excessive, but it's a model where I like to see layers of security that depend on different, uncorrelated failures being required to bypass them.

Today if you want to get into an account using "FIDO2 as MFA" you need both the account credentials or ability to reach the Fido prompt (say password reset), and the hardware token device (with optional pin). The device alone being compromised shouldn't get you into the account.

>>briHas+i4
That's a pretty neat solution. I like that idea.

If you wanted to go a step further, you could use a smartcard with hardware PIN reader as a PKCS11 crypto device, and use that to decrypt the long lived keys in the store, then pass it back to the host encrypted by a platform-protected key to be decrypted and used.

If you could get the right implementation specifics together, you could likely then have the smart card simultaneously re-encrypt the credential with a key bound to PCR state of the TPM via a policy. You'd then decrypt that ciphertext on TPM without a PIN, but conditional on PCR state of a couple of PCRs that represent your system like the secure boot toggle state and allowed CAs.

That lets you be a bit more "cross device" than a fully TPM solution does, though your certificate technique works fine as long as you keep an offline backup for enrollment if anything changes on your system.