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. 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. 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. > So with that in mind, here's how I might prefer to go about it. The > yubikey supports two 'configs' or 'slots'. I propose we exploit that. > First we use config 1 for OTP challenge-response - but we only use that > to authenticate to the system. Oh yes, definitely. Sorry for not mentioning that - I focused on the ecryptfs related things in my original post. Yes, a user with a Yubikey would most likely use OTP validation to log in to the system. > Then we use a static long passphrase for > the ecryptfs passphrase. The long passphrase has low entropy due to > modhex (to satisfy the requirements on valid characters), but the pam > module can take the long low-entropy passphrase and mogrify it into a > shorter high-entropy one. (That, of course, continues to be our > wrapping passphrase, not the actual ecryptfs key.) > > 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 > Anyway that's how I'd go about it off the top of my head. I got worried > when the Yubikey Manual 2010-09-16.pdf seemed to tell me you couldn't > have one slot do challenge-response while the other did simple OTP or > passphrase, but the ykpersonalize manpage said differently, so I tested > it - and it worked fine. Yes, that is definitely supported. > Separately, I had a question regarding challenge-response mode. In > Yubico chal-resp mode it takes a 6 byte challenge and generates OTP. > But the doc doesn't say what piece of data is replaced by the 6 byte > challenge. Is it the uid (bytes 0-6)? I'm not sure actually. I think so. I'll ask the firmware guy on Tuesday, or you could AES ECB decrypt the OTP and see for yourself =). /Fredrik _______________________________________________ Mailing list: https://launchpad.net/~ecryptfs-users Post to : [email protected] Unsubscribe : https://launchpad.net/~ecryptfs-users More help : https://help.launchpad.net/ListHelp
