#745 Yubikey: Re-encrypt container with a new random challenge-response at each save


To improve the security of the Yubikey implementation, please implement a random challenge that is re-generated each time the container is saved. This would avoid detection by HID-sniffing trojans of the HMAC hash response from the Yubikey, which could be used by an attacker to later unencrypt the container. I'm definitely not a crypto expert, but I'll outline below how I think this could work. Details of the discussion that lead to this request can be found in the thread at:

First, when a container is created with a Yubikey and the Yubikey is initialized, the secret key that is saved in the Yubikey would also be stored inside the Password Safe container (as I understand it, this is already done). After that, each time the container is saved, Password Safe would (1) generate a new random challenge string, (2) ask for (or reuse, if previously stored) the user's password, (3) calculate the HMAC from password|challenge (or a hashed version) using the stored secret key, (4) encrypt the container with the HMAC (or PBKDF transformation), and (5) finally store the challenge on the outside of the container in a plaintext form, similar to how a salt is stored.

When unlocking the container, PwS would (1) get the stored plaintext challenge from the outside of the container, (2) ask for the user's password, (3) send password|challenge (or a hash) to the Yubikey, and (4) unencrypt the container with the HMAC response from the Yubikey (or PBKDF transformation).

Two issues with this implementation were discussed in the above thread, including the susceptibility of automatic backups (or cloud-based backups, etc.) to attack with a previously-used HMAC, and an inconvenience when using multiple containers with a single key. I feel like the trade-offs with these two issues would be worth the added security for me.

Thank you to the developers for all the hard work!


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks