I’d previously written about the Yubikey 5 and how we could use it to solve various use cases and when to trust it. Personally, I think it’s a great device for corporate authentication solutions.
But…
This week, Yubico released an advisory that stated that ECDSA private keys could be stolen from a Yubikey 5 that’s running firmware older than 5.7.0 (or 2.4.0 for the YubiHSM). This is due to a flaw in the cryptographic libraries written by Infineon and discovered by NinjaLab.
I don’t normally write about specific products, but I was asked to take a look at the YubiKey series (primarily 4 and 5) and write up a summary of when and how it can be used.
This is timely, because CISA is pushing for access management enhancements and recently published a chart for phishing resistance.
I thought this interesting; typically I’ve looked at this from a user perspective (“can I use this to secure access to my bank account?
Every day we hear of yet another data breach. One common reason is because of password compromise. The problem may be because of successfully phishing; it may be due to password re-use; it may be due to brute force attacks; it may just be weak passwords.
So it is now considered best practice to use some form of Multi Factor Authentication.
To quickly summarise, MFA is 2-or-more of the following factors:
We’re all used to using passwords as an authenticator. However, passwords have a number of problems. In particular people tend to re-use them on other sites (so if one website was broken into the password used there may also work on another site). Also passwords are susceptible to replay attacks (even if you force a password change every 90 days, there’s still a large window of time where a stolen password can be used).
One of the major threats that companies are concerned about is “insider threat”. According to some Data Breach Incident Response (DBIR) analyses, insider threat may be the 2nd or 3rd major reason for data loss. It’s interesting to note that the insider threat is way down in the actual number of incidents, but they count for a larger number of successful data loss incidents because the insider knows where the data is, may have legitimate access to the data, and may know the controls that need to be bypassed to exfiltrate it.
So I decided to play a little bit with google authenticator on my systems that are visible to the internet. ie my linode, Panix v-colo and ‘bastion’ host at home.
The way sshd works, if you authenticate with public keys then PAM “auth” doesn’t seem to get called. So this is pretty much for “ChallengeResponse” (instead of “password”) authentication. Which makes it great for my need; if I’m coming from one of my own machines with my SSH key then I’m not impacted.
