authentication to arbitrary web sites
YubiKey authentication to arbitrary web sites that don't explicitly support YubiKey (U2F or similar) by themselves archived. Some notes:
- YubiKey https://packages.debian.org/search?keywords=yubikey-personalization-gui
- backups are sorted in case a yubykey breaks or gets lost
- because the same HMAC-SHA1 secret can be written to all YubiKeys
- used "configuration slot 2", which somehow works with short touch as well
- "configuration slot 1" can be used for something else
- keepassxc installation hints
- enable keepassxc browser integration
- set keepassxc to close its database when closed (minimized to tray)
- set keepassxc to always save the database on changes
result: Firefox's password manager uses keepassxc as backend. And keepassxc's database gets unlocked by password plus YubiKey. (It's and/or. Would also be possible only password or only YubiKey.)
- Firefox 54 with new add-on API (Web Extensions) broke it - https://github.com/smorks/keepasshttp-connector/issues/46#issuecomment-346847247
- (Or keyfiles, but keyfiles make no sense since when using YubiKeys.)
- (Qubes and Qubes USBVM compatible.)
- All implemented using Free, Open Source and Libre Software.
In total there are3 factor authentication to arbitrary websites etc.:
- first factor: password (to unlock keepassxc database) ("something you know")
- second factor: YubiKey with key press (to unlock keepassxc database) (HMAC-SHA1) ("something you have")
- third factor: google authentication / AndOTP (HTOP one time passwords) ("something you have")
(Currently there is no factor "something you are", but I wouldn't know how to implement it for arbitrary websites. Above authentication setup should be complex [read breakage, difficult, lockout oneself] and secure enough. Rather than trying to hack these three factors, Malware would rather just hijack the web login session.)
- Configured yubikey configuration slot 1 with static password and configured yubkkey configuration slot 2 with challenge response. (google) U2F still working. Pretty awesome.
- Could even enter my BIOS password using yubikey using a static yubikey password.
- Static password works even for full disk encryption password entry. Either as a single factor or to increase the lenght of the password. It acts as a USB keyboard. Even works with Qubes. (2FA vs BadUSB.)
- Yubikey U2F - no backup possible. (But U2F supporting services might support alternative login methods or multiple U2F (yubikey) keys.) Not an issue, since we won't be using yubikey for U2F.
- Yubikey static passwords / HMAC-SHA1 challenge response: (paper) backup easily possible.
- It might have a bug resetting keyboard layout to en-US but it's not a big deal.
- Yubikeys supports storing OpenPGP (GnuPG / gpg) keys, OpenSSH keys, but I wouldn't trust it. Another yubikey model had a PIN bypass bug. ( https://developers.yubico.com/ykneo-openpgp/SecurityAdvisory%202015-04-14.html )
Static Password vs Challenge Response
- deny unauthorized decryption of notebook full disk encryption when notebook is powered off, gets stolen and user password has been sniffed
- [A] temporarily grab YubiKey for a moment, temporarily attach to a smartphone or so, press YubiKey button, therefore steal the static password ("very easy")
- [B] temporarily grab YubiKey for a moment, extract challenge response secret key from smart chip through side channel or exploit ("harder")
- [C] bruteforce or sniff (camera / side channel) user entered password
- [D] unauthorized access to notebook (theft)
We assume the adversary has succeeded with [C] plus [D].
boot full disk encryption authentication methods:
- YubiKey static password : fails against adversary capability [A]
- YubiKey static password : fails against adversary capability [B]
- YubiKey challenge response: safe against adversary capability [A]
- YubiKey challenge response: fails against adversary capability [B]
Both authentication methods are easy to program into YubiKey, allow easy legitimate clones to other YubiKey and (paper) backups.
In other words, YubiKey static password fails when an adversary can get a moment of access to it easily. YubiKey challenge response is clearly superior.
However, YubiKey challenge response is much more complex (speak: lockout risk) and time consuming to develop, research, and setup for Qubes OS.
Qubes OS YubiKey luks challenge response:
|Static Password||Challenge Response|
|BIOS password entry||Yes||No|
|Boot Password Entry for Full Disk Encryption on Debian||Yes||Yes|
|Boot Password Entry for Full Disk Encryption on Qubes OS||Yes||difficult|
2FA (google authenticator) works against simple phishing (user sending password by email somewhere). Or in case the server's password database gets hacked but the 2FA database not.
Against local compromise by malware nothing helps as the attacker can simply takeover the login session. It's usefulness is limited indeed with these tools available.
Yubikey can help to strengthen passwords for login, screensavers, BIOS and full disk encryption. Or a stolen, powered off notebook with password on camera can still be safe.
|Simple Password phishing ||Yes |
|redirection to phishing website ||No |
|server password database hacked||Yes |
|local compromise ||No |
- User replying to fraudulent password request by e-mail.
- With the password alone, no fraudulent login is possible.
- Such as DNS spoofing or man-in-the-middle attacks.
- The user has to spot the browser SSL warning.
- When the server password database was hacked, but the 2FA database not, malicious logins are prevented.
- By Malware
- No protection against session hijacking.
https | (forcing) onion
This is a wiki. Want to improve this page? Help is welcome and volunteer contributions are happily considered! See Conditions for Contributions to Whonix, then Edit! IP addresses are scrubbed, but editing over Tor is recommended. Edits are held for moderation.