I intend to implement Windows Hello similar to the Touch ID implementation on Mac, that would offer the possibility to be set as a vault option and require the user to e.g. provide a Windows Hello PIN to save to and retrieve vault passwords from the Windows keychain.
Other than the Mac keychain, there is no extra security attribute for a Windows keychain item, that indicates whether Windows Hello is required to access the keychain item.
So, which way to go? I see two alternatives I would offer here for discussion:
the integrations-api could be widened again with an overloaded loadPassphrase method, that has an additional parameter to indicate whether to use Windows Hello or not
the KeychainEntry record in intetegrations-win could be widened with an additional field to indicate whether to use Windows Hello or not
Is (again) not good API design, since this would add another method with the same signature, right?
i assume this parameter can simply be ignored when reading from the keychain, or am i wrong?
My general question is, why not enforce by code using Windows Hello and reuse the current method? I.e., if the requiresOSAuth parameter is true, we only or make an additional/ call to the Windows Hello API.
Is (again) not good API design, since this would add another method with the same signature , right?
Nope. The suggestion was to overload loadPassphrase, as you suggested and merged for storePassphrase for Touch ID.
i assume this parameter can simply be ignored when reading from the keychain, or am i wrong?
You are mistaken.
First, there is no overloaded loadPassphrase method with an additional parameter, as Mac stores keychain entries with an optional additional SecAttri, that determines on load whether to present Touch ID or not. There is nothing like this for Windows.
Besides, Windows Hello is very different from Mac and needs a different implementation on the security side, as it offers a keypair, and the secret part can be used to sign and encrypt a vault passphrase. Now, the Windows keychain JSON file stores ciphertext and salt for an encrypted vault passphrase, but how to determine, which decryption scheme should be used?
That’s why I suggested the two alternatives.
My general question is, why not enforce by code using Windows Hello and reuse the current method? I.e., if the requiresOSAuth parameter is true, we only or make an additional/ call to the Windows Hello API.
I’ll provide the required code and create a PR, that can be discussed then.
The Windows keychain JSON file stores ciphertext and salt for a vault, where the encrypted vault passphrase is protected by WinDataProtection. The same JSON file is used to store ciphertext and challenge for a vault, where the encrypted vault passphrase is protected by WinHello. Both variants use the same KeychainEntry.
But how to determine, which decryption scheme should be used on loading a vault passphrase? See my original question. I’d prefer number two, where an additional field is added to the KeychainEntry record.
