[idea] Use second factor as challenge about mkinitcpio-ykfde

[eworm-de]

This already supports second factor on top of the stored challenge. What's wrong with that?

[Vincent43]

Challenge is stored in clear available to anyone. If someone has access to yubikey, the response and at least half of luks passphrase is avalaible . That means it works same as static password stored in yubikey. If second factor is used as challenge, access to yubikey alone gives nothing. Also stored challenge doesn't have any useful purpose if second factor is needed anyway and can be used as challenge instead.

So I propose that stored challenge will be used only in one factor case.

For two factor user password will be used as both challenge and second half of luks passphrase.

[eworm-de]

Challenge is stored in clear available to anyone. If someone has access to yubikey, the response and at least half of luks passphrase is avalaible . That means it works same as static password stored in yubikey.

No. Because you need Yubikey and challenge at the same time and place.

If second factor is used as challenge, access to yubikey alone gives nothing. Also stored challenge doesn't have any useful purpose if second factor is needed anyway and can be used as challenge instead.

Wrong. The challenge (and LUKS passphrase) is changed on every boot. So consider the stored challenge is a dynamic salt: If anybody manages to calculate the response (aka LUKS passphrase) it is invalid on next boot.

So I propose that stored challenge will be used only in one factor case.

No. See above.

For two factor user password will be used as both challenge and second half of luks passphrase.

That does not bring any benefit but extra code complexity.

[Vincent43]

Challenge is stored alongside encrypted disk so it doesn't count as a factor. Without access to this data everything is pointless. Having yubikey is enough to get correct response.

Changing the challenge doesn't bring any additional security as still possessing same yubikey give you valid response. You (and attacker) don't have to know anything about challenge (if stored) and response as it's working automatically with correct yubikey.

Also one time access to offline encrypted data (which allows for copying luks header) or online decrypted data (which allows for dumping luks encryption key directly with dmsetup table --showkeys)is enough for an attacker to save and use current challenge/key forever unless you reencrypt whole disk with different luks key. Changing challenge/response doesn't help at all with above. I already had this discussion in cornelinux/yubikey-luks#1 (comment) .

One Time Password concept is only useful where independent oracle exist i.e. remote server. It's not useful in case of physical disk encryption when decryption is done offline with environment controlled by whoever has access to data.

Also this adds actual extra code complexity and in worst case scenario can break things. Moreover if stored challenge is damaged or lost, luks key cannot be decrypted with valid yubikey and valid password.

I already explained benefits of using password as challenge. I didn't look at code but as password logic already exist it's a matter of moving it to the place before challenge-response generation scheme and providing it as input instead of what is stored in config file.