document Yubikey qubes-dom0-yubikey / qubes-app-yubikey

[adrelanos]

https://www.qubes-os.org/doc/yubi-key/ is out of date. https://github.com/QubesOS/qubes-app-yubikey is in Qubes repository, but undocumented. Couldn't make it work, so also cannot document it.

yubikey settings:

• configuration slot 2
• HMAC-SHA1
• HMAC-SHA1 mode Variable input
• secret key including spaces (a space after every two characters)

That secret I copied to dom0 /etc/qubes/yk-keys/yk-secret-key.hex. (Including the space every two characters.)

test "x$correct_response" = "x$response" will show different strings, hence the script fails exiting 1.

[adrelanos]

Looks like https://github.com/QubesOS/qubes-app-yubikey/blob/master/bin/yk-auth requires HMAC-SHA1 mode fixed 64 bit input. That works for me. HMAC-SHA1 mode Variable input does not work.

[adrelanos]

The video referenced under https://www.yubico.com/products/services-software/personalization-tools/challenge-response/ shows HMAC-SHA1 mode Variable input. So currently the documentation is wrong.

• Should / can https://github.com/QubesOS/qubes-app-yubikey/blob/master/bin/yk-auth be made compatible with HMAC-SHA1 mode fixed 64 bit input?
• Should / can be https://github.com/QubesOS/qubes-app-yubikey/blob/master/bin/yk-auth be ported to HMAC-SHA1 mode Variable input?

What is better anyway,HMAC-SHA1 mode fixed 64 bit input or HMAC-SHA1 mode Variable input?

[marmarek]

I'd go with 'fixed 64 bit input'.

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

[adrelanos]

Note to self: /usr/bin/yk-self

[adrelanos]

Working on it. Pull request soon.

[adrelanos]

https://github.com/QubesOS/qubes-doc/pull/478

[adrelanos]

//cc @mig5

I am also mentally processing these blog posts.

• https://mig5.net/content/yubikey-2fa-qubes-redux-adding-backup-key

I doubt yubi_auth $KEY1 || yubi_auth $KEY2 is necessarily. You can just write the same HMAC-SHA1 ("AESKEY") secret into a backup yubikey? Any reason against that?

• https://mig5.net/content/yubikey-challenge-response-mode-qubes

Once above pull request is merged, I might add on how to optionally set yubikey only and how to use it for login and lightdm.

[adrelanos]

Once above pull request is merged, I might add on how to optionally set yubikey only and how to use it for login and lightdm.

Correction: It's now all documented.

[mig5]

@adrelanos yes you're right that you could have an exact clone of your primary yubikey, but if that yubikey is stolen or its key compromised in some way, then you can't rely on your backup either since it's identical. So you'd have to regenerate the key on the secondary rather than just revoke the key of the former in your config/script

I only blogged what works for me :) and yes as per your other issue, I use it in /etc/pam.d/xscreensaver as well as /etc/pam.d/login and /etc/pam.d/lightdm - anything less feels like backdooring yourself with single-factor auth.

Let me know if you would like copies of those files from my system to get the positioning right etc (I had varying degrees of success depending on how early the 'auth include yubico' was referenced)