YubiKeys
I have a pair of YubiKey 5C NFC, which I use for authentication a lot. They’re small USB-C authentication devices which can generate multiple types of keys and are usable for different types of authentication.
The keys generated on-device cannot be extracted, which means that the only way to steal the keys is to physically steal the device itself.
This article includes some of the practices I follow and recommend, as well as some warnings of things not to do.
Two factor authentication
The obvious usage is 2FA. On supported websites, when logging in, they’ll prompt me to press the button on the key. This is very simple and convenient to use, and no need to copy numbers from a dedicated hardware device.
It’s pretty important to have some form of backup in case the key is lost. In my case, I keep a second off-site. I recommend a similar arrangement whenever possible.
SSH Keys
I use a YubiKey to generate my SSH keys. This has been supported by SSH for a while now (since version 8.2), and they can be generated using:
ssh-keygen -t ed25519-sk -C "A key for some service" -f id_someservice
This generates a key on the YubiKey device itself. The key itself cannot be extracted, but also requires the on-disk file to be used. This means that if someone snatches my YubiKey, they still can’t use my SSH key. And if someone extracts the file from disk, they still need the YubiKey.
Using keys inside the YubiKey also reduces the need for an ssh-agent. The
agent mostly keeps the keys in-memory, so one doesn’t have to type the
passphrase over and over. Since there’s no passphrase, this is no longer an
issue. On top of that, one does have to tap the Yubikey in order to use the
keys, so they can’t be used without a manual confirmation (which is just a tap
of a button). The tap also cannot be spoofed by someone with remote access to
the system. This yields stronger security than a passphrase, and far more
convenience.
Of course, if someone extracts the file from disk AND steals the YubiKey, then it’s game over. There are, after all, plenty of scenarios that we just can’t avoid…
Side note
There’s obvious attacks to some of these practices, like “What if the adversary has a forensics lab that can crack a YubiKey?” or “What if an organisation has broken the encryption on the keys?”.
Before you start to plan against how you’d prevent the NSA from looking at your email, please keep in mind that they could just as a well buy a wrench:
Sudo prompts
Typing a user password to sudo is annoying, repetitive and error prone.
Instead, I’ve set up sudo to use my YubiKey instead. This is what a sudo
prompt looks like:
$ sudo whoami
🔐 Confirm user presence
root
The Confirm user presence prompt indicates that one should press the
YubiKey’s button. Note that, in order to even run sudo, one needs to first be
logged into an unlocked interactive session, which is something else entirely.
Hint: If you want to set this up, see pam-u2f.
Polkit prompts
I have polkit set up to also prompt with a YubiKey. All the same details apply, but it’s just at GUI prompt rather than a CLI prompt.
System login
My system prompts for a disk decryption password on boot, so getting to a non-root shell requires this passphrase.
There’s nothing crazy and special here, but I do want to point out that logging into the system or unlocking the disk with a hardware key alone is a terrible idea. Imagine you set up your system so that you can log into it with just a hardware key. Now imagine that you’re on vacation in a hotel, and someone bursts in and steals all your electronics. The hardware that’s unlocked and they key will, more often than not, remain physically close.
It’s the same idea as carrying a suitcase with a lock, and having the key for the lock tied to the suitcase. This particular suitcase though, has access to all your online accounts, email, banking, etc.
For disk encryption, a good old passphrase is usually still the best idea. It should be one of the few passwords you need to remember anyway, and it should obviously be unique.
Screen locker
Most of the same arguments above apply to a screen locker. Unlocking the screen requires a password. If the screen locker would somehow crash, then the compositor won’t unlock the screen so no stranger can use the laptop.
Configuring a screen locker to use a YubiKey is also a kinda bad idea. If a random attacker were to steal your stuff, they’ll take both things together. It’s again a case of “leaving the key in the lock”.
Again, usually a password or passphrase is best here. If your hardware has reliable fingerprint sensors or alike, that might be a good idea, but it depends a lot on the hardware.
Personally, my local user’s password is only used for unlocking the screen, which makes it a bit safer, since no other process or program ever handles it.
Password Manager
It’s ideal to use a password manager. Too many experts have written on this, so I won’t repeat their points, but mostly summarise:
- Reusing passwords is dangerous.
- Humans are terrible at coming up with unique passwords.
- Humans are even worse at remembering MANY unique passwords.
My advise is to remember the most important passwords (system, email, password manager, etc), and then keep all the rest on a password manager.
Some password manager can be unlocked with a hardware token (e.g.: A YubiKey). I personally don’t use this; I prefer to type the password manager’s main passphrase often. Typing it daily makes sure I won’t forget it.
Summary
- Use a hardware token for 2FA whenever possible.
- A hardware token is a good mechanism to authorise special operations, like
sudo. - However, it’s a bad idea to use a hardware token a sufficient mechanism to gain access to the system.