Quoting Fredrik Thulin ([email protected]): > Serge, thanks a lot for your feedback! > > On Sun, Apr 10, 2011 at 5:55 AM, Serge Hallyn > <[email protected]> wrote: > ... > > So pam first reads your password, then passes that plus your username > > back to the key for it to encrypt, right? > > Yes. Well, HMAC-SHA1 hash - not encrypt. > > > The only thing that worries me is that the authentication is not > > really partly based on 'something you have'. Because if I can play > > man in the middle and read your password and the hmac once, I can > > replay them any time I want. > > That's absolutely true for the current version. I know of two ways to > improve on this, both with their drawbacks and advantages. > > 1) Every time the user logs in, you take your challenge C1 and > generate R1 using it. You then generate another challenge C2 and have > the Yubikey generate R2 using C2. You rewrap your mount passphrase > using R2, so this is the response that has to be generated the next > time. The challenges could be "$username:$password:$nonce", with > $nonce stored in plain text on the computer.
How does this help? If I MITM while you are, say, authenticating with (C15:R15) and you pass (C16:R16) as the next to be used, then I can simply authenticate with C16:R16 and hand over a dummy C17:R17. Yes, I cost you future access to your data, but that doesn't bother me :) I know right now you see this as being for local-only use, but honestly that seems very un-unixy to me, and I think you pretty much have to, eventually, implement a way to do this remotely :) Presumably with a patch to ssh which does the challenge-response and passes data back and forth to the remote PAM module. > 2) You rig it so that every time the correct response is presented, > you are able to decrypt a file that contains the HMAC key inside the > YubiKey (which you know, since you programmed it). You can then > randomize a new C2 and calculate what R2 would be, and re-encrypt the > file with the HMAC key using R2. This daemon is going to get access to your ecryptfs key temporarily anyway, so I don't think that giving it access to the HMAC key gives anything away. Just make sure to reliably clear all memory :) So I like option 2, personally. In a later email you ask about re-wrapping the wrapped ecryptfs passphrase on every mount. I'll answer here: it promises to be disastrous, as several people are bound to end up (through full disk, or badly timed ctrl-c, or something else) corrupting their copy. So just make sure that the user has another copy of the ecryptfs key! Maybe offline, maybe wrapped with login passphrase, maybe protected using another token, maybe written in hex on a post-it stuck on the monitor :) Oops, not that. > There's an implementation of offline validation using Yubikeys with > scheme #1 that I'll merge and release in the yubico-pam project next > week. Cool, looking forward to it. You might also push some test python code which does the same steps for people to play with. In fact, you seem to be focusing on people doing full home directory encryption - and that's fine as I suspect that's the model we as a whole are trying to push. But please consider users like me, who have $HOME unencrypted with several separate ecryptfs dirs spread about. (See the new options to mount.ecryptfs_private.c in natty's ecryptfs-utils) So I guess, for my own use, I'd actually just want to stick with a non-changing wrapping key, so that I can support 5 (for example) different ecryptfs directories with different passphrases. For that case, I'd actually want to use your current model! :) But without pam (since it's not at login), so something amounting to: pw=$(dialog --passwordbox Password 10 20 --stdout) printf "%s" $(ykchalresp -2 -H $pw) | ecryptfs-add-passphrase mount.ecryptfs_private work (now ~serge/work is decrypted and available :) (With the above being scripted of course) In fact maybe I'll just start using something like this for a bit to see how it works for me. ... > > This way authentication isn't susceptible to replay. We get a nice long > > passphrase for ecryptfs. We don't need any changes to the ecryptfs > > password handling. And it's simple. > > I totally agree that OTPs should be used for authentication (that's > the core Yubikey concept after all). However, I think C/R is much > better than static passphrases since they > > 1) require you to know the right input, so someone that gets a hold of > your Yubikey for a few minutes can't just connect it to a computer and > press the button to get your wrapping passphrase > 2) provides 160 bits high entropy output (since you have an 160 bits HMAC key) > 3) can be triggered through API call (if that is permitted through > configuration), thereby not requiring the user to press the button > twice - once for log in and once for home directory decryption Yup. -serge _______________________________________________ Mailing list: https://launchpad.net/~ecryptfs-users Post to : [email protected] Unsubscribe : https://launchpad.net/~ecryptfs-users More help : https://help.launchpad.net/ListHelp
