The hardware U2F device would need to store some data (stream, be it a file, string, etc) and feed it directly to KeePass, which would understand it as a keyfile.Īccording to, indeed FIDO doesn't fit on KeePass needs. And we still remain vulnerable to a malware reading decrypted data from KeePass RAM once it's delivered from the chip.Īpart from the RAM vulnerability, the 2nd best solution I see would be to protect against keyloggers and clipboard interceptors.

I also guess that, by how KeePass works, the whole kdbx file would need to be decrypted every time it's opened, which may become very slow depending on the chip performance and db file size. IDK if processing decryption is supported by PKCS#11. I guess the best solution would be to have something like PKCS#11 in which the key is stored on the chip and never leaves it, and decryption would be executed by the chip itself. Or intercept from RAM its decrypting key then decrypt the file. If somebody develops a malware to intercept KeePass, then regardless of how we handle decrypting its DB, as soon as it's decrypted, the malware can just read it from RAM. I think AlexVallat - is the best explanation on this.

Fido u2f