> Security keys offer almost unbeatable security and can protect against a variety of threats, including nation-state attackers.
Alright, I'm not a security expert, but I'm not completely illiterate to basic computer security. Anyone care to chime in how this is much more secure than a two-factor app?
Sure there's the obvious, nobody can just copy the two-factor app off my phone with all the codes and have the same codes (I've upgraded phones and taken my codes with me before...) but whose to stop someone from cloning a Yubico key?
Again I'm not an expert, but I do want to know if this is purely marketing hype or if there's some security to Yubikey and friends that I'm not aware of.
Also pardon me if I confused two-factor as the Google Authenticator app. Too many "factor" terms get a bit confusing after a while.
> whose to stop someone from cloning a Yubico key?
That is precisely what these devices are designed to stop. The device has a private key stored in hardware in a way that it cannot be retrieved by software. When you use one of these devices you dramatically decrease your number of attack vectors because now the attack has to happen physically. Someone has to actually steal your physical key. And because this is your "second factor", if that happens they still also have to have your password.
Two-factor apps get closer to this, but they usually can be copied. For instance, 1Password can be set up to mimic Google Authenticator.
> I do want to know if this is purely marketing hype
This is most definitely NOT marketing hype. It is the current security best practice.
I didn't know about 1Pass, I've been a paying member for a while. I'll try that out! But to put a finer point on your actual statement, I usually screenshot the MFA setup in case my phone gets lost, so I can easily re-set it up.
For those who aren't aware, the author of the post works for them. Maybe a founder; it's a little hard to tell. I've run across him doing exactly this in the past. Bad form, and (having looked at it in the past) the product he's flogging is amateurish.
Not quite - if someone steals your 1Password (or equivalent) database with TOTP seeds in, they need to crack the password on that, then have full access to everything. If they get the password from the other end (e.g. the site you log into), they can probably log into that specific site (they will have the TOTP seed), but not anything else. In general, there are more attackers looking at the site end than at the client password DB end.
Probably wouldn't be a bad idea to have a distinct password vault for TOTP seeds, although they'll be stored on whatever device you generate codes from anyway (hopefully in a secure way). At the very least, it might be helpful for moving between TOTP devices without needing to do the random steps required by different services!
Since, once unlocked, 1password as of version 7 stores everything de-crypted in memory, ANY attack on a host with an unlocked 1password keychain which can exfiltrate memory across processes can steal everything.
It's pretty obvious why this changed, however, it is a major increase in exposure and a terrible change overall. It is discussed in [1] and mostly the answers aren't very satisfying as demonstrated in [2].
Lockheed has a great deal of their MFA keys compromised because the factory that manufactured them had been breached for a while and nobody had noticed. Supply chain attacks are performed constantly against large, known entities and this case shows why they are so pedantic about security and justified in their paranoia. The problems have been execution of the policy and the costs of compliance.
Ah this sounds familiar... Probably saw the article here on HN ages back and forgot. I mostly ask cause I don't have one of these keys but if I were to consider getting one I'd want to know what a good option would be.
You should look for a vendor which understands that knowing the secret key inside the Security Key (that's how all the vaguely cheap ones work, they have a random secret AES key inside them, that's enough to do everything else securely) is a terrible idea and so they should arrange for the key to be chosen randomly and never recorded at all.
With SecurID and similar technologies vendors technically didn't need to retain the secrets inside those devices after they'd been manufactured and shipped, but you can see the practical temptation.
On a smaller scale, since the system doesn't use a shared secret you should just swap a brand new Security Key with somebody else or if deploying to an organisation just muddle them and let people pick whichever one they want. You don't care which key you have, the more random the better.
> have they had external security firms try to steal the private key?
Definitely, it's an expensive vulnerability to simply reveal though. YubiKeys are proprietary so they can't be audited by non-contracted third parties. There are FOSS security keys that don't have that problem though.
The two factor app (say, TOTP) involves a _secret_ used to generate a changing value and so bad guys can do either of two things:
1. They can steal the secret, from you or from the other party (the service you're authenticating to)
2. They can relay your answer, without knowing the secret and since the answer is genuine their relayed answer will be accepted. Example you type the One Time Code into https://fakebank.example/ thinking it is your bank, then the bad guys simply paste that same code into https://realbank.example the actual site of your bank and it works - they get into your account.
FIDO Security Keys don't use a shared secret, instead they use public key crypto. Your Security Key proves it is still the same key as it was when you registered, but the remote site doesn't have any secrets so they could even _publish_ the data they store to authenticate you and that wouldn't matter to the system's security.
And it relies on the web browser to tie the FQDN into the data signed. If you press the button on the Security Key on https://fakebank.example/ the results are only proof for fakebank, operated by the bad guys, if they forward it to https://realbank.example/ it won't work because the name is wrong and it doesn't match.
Does that help? There are a bunch of other cool things about Security Keys, but those are the main ways it's simply better for security than a conventional TOTP-style second factor.
Simple: security keys combat phishing, two-factor apps do not. A security key doesn't just authenticate you to a site: it also authenticates the site to you.
I think I get what you are trying to express, but rather than "it authenticates the site to you", I think that should be phrased "it prevents you from authenticating at a site pretending to be some other site.
evil.com can still claim to be mysite.com and trick users into using their security key there, no?
It would presumably have to trick the user into "registering again" since there is no valid key handle for FIDO2 (not sure about classic U2F), but I doubt that users would notice the difference in flows.
The real win is that this spoof would still not give evil.com a credential scoped to mysite.com, but a user would be none the wiser that they are on a different site than they expect (which can still be problematic depending on the nature of the site).
Suppose the key allows mysite.com to let you see your emails, send more emails, and send money to people, etc. Basically mysite.com let's you see and do interesting things after you've authed.
Even if evil.com gets you to register and present your key, they cannot forward it to mysite.com. Even if they go to all the trouble to completely mitm you and the site looks identical to mysite.com, they cannot get the emails or get it to send money.
This is because evil.com cannot pretend to be you when they interact with mysite.com no matter what you've given them.
It's going to be hard to trick me into thinking I've logged into my gmail if none of my emails are there!
Unless they somehow convince you to put your yubikey in the mail and physically send it to them...
True, this would defend against many practical attacks and is a huge security win by itself.
I'd just be careful about overly relying on this property or calling it anything like mutual authentication:
If an attacker can make an educated guess about a user's account contents, they could still convince them to provide additional personal information once they let their guard down after authenticating.
Security keys are two factor as well. In fact there are multiple different types of 2FA with different security levels. SMS 2FA is one of the weakest. Push Login is moderate. Scanning encrypted barcodes is highest and also phishing proof like FIDO keys.
> Scanning encrypted barcodes is highest and also phishing proof like FIDO keys.
I have never seen a solution like this, but I can't see how it would avoid simple relay phish, it seems as though bad guys can just get themselves a legitimate encrypted barcode and have their victim scan it.
Maybe you haven't explained this solution properly, do you have a link?
Speaking as someone who writes code for authentication systems, it's not marketing hype. These physical U2F authenticators are more secure by design than the number based authenticator apps.
Since the Yubikey (and friends) operates by generating a private key on the device itself, inaccessible to software, it means that the key is hard to clone. They'd have to steal it off your person. Combined with generating a unique key pair for every website and checking that the website is what it claims to be, this means that the key is resistant to replay attacks, which number based authenticator apps are vulnerable to.
That isn't to say that it's immune to phishing, but it's much, much harder to phish someone who is using a Yubikey because an attacker would need to compromise someone's DNS configuration or SSL configuration to impersonate the website, at which point... why are they bothering with phishing?
These are basically tiny hardware security modules. The premise of an HSM is that you have a hardened processor that contains the secrets and performs asymmetric crypto operations on request. Ideally, the device is designed such that the secrets never leave a crypto boundary. The big expensive ones will offer facilities to transfer keys, but only over an authenticated, encrypted connection to another device certified by the manufacturer[1].
Yubico has some FIPS certified devices[2], which means that they've presented a design that shows the device has mechanisms to prevent secrets from being extracted, and they're only using algorithms known by NIST not to leak secrets.
> Also pardon me if I confused two-factor as the Google Authenticator app.
Multi-factor authentication is about managing risk, and discussions about risk are naturally fuzzy and vague.
I'll try a concrete analogy; consider firearms safety.
Some typical rules[3]: 1. keep the weapon pointed down range at all times, 2. keep your finger out of the trigger well, 3. treat the weapon as loaded at all times.
Each rule is a factor, and to accidentally hurt someone you have to violate all the rules at once.
Multiple factors work best if they are orthogonal, that is, when a given action results in only breaching a single factor. That's why factors tend to be phrased as "something you know," "something you are," "something you have".
The authenticator app and a Yubikey are doing the exact same thing: they're establishing the "something you have" factor.
Since the two factors work when an attacker must both obtain the device and get your password, if your phone has both passwords and authenticator apps, the additional factors aren't minimizing that risk.
[1]: The automatic vendor lock-in makes it a great business model...
It isn't. SW can be updated and is usually open-source and mostly secure.
HW not so.
At least two HW backdoors have been found in chips such as this one in earlier versions, the first using an improper RSALib RSA variant (developed by NSA or Mossad). The source for the second, SCADA, is unknown.
So any nation state wanting the most people to use it, will advertise it as such. "unbeatable security and can protect against a variety of threats, including nation-state attackers."
Obviously they are biased – they are in the business of selling hardware, not software, but their reasoning still makes sense to me.
It's arguable whether "destructive updates" that invalidate all existing registrations should be allowed, but that could have its own problems in terms of availability if not clearly communicated.
On a related note, I wonder if there is actually a more secure way of preventing illegitimate firmware updates in JavaCard/GlobalPlatform than randomizing the card manager keys, which is what Yubico does for the NEO: https://www.yubico.com/2016/05/secure-hardware-vs-open-sourc...
It might not be impossible, but surely non-trivial. Add to that that it has to be done in a undetectable way and the key owner needs to be parted for the key in the time it takes to make the clone.
You'd probably destroy the key's shell in the process of getting to the microchip (you can't get to the private key via the USB connector by design, so decapping is probably the only way to do it), so you would have to have a clone ready that looks exactly like the key you've just disfigured to get to the secret key.
Moreover, if a physically undetected clone is managed, it will be detected soon through the spec. The WebAuthn spec includes monitoring an always increasing counter for each key/site pair. One of the clones will start to fail.
So really there's no point in cloning. Straight up theft is the bigger concern.
Alright, I'm not a security expert, but I'm not completely illiterate to basic computer security. Anyone care to chime in how this is much more secure than a two-factor app?
Sure there's the obvious, nobody can just copy the two-factor app off my phone with all the codes and have the same codes (I've upgraded phones and taken my codes with me before...) but whose to stop someone from cloning a Yubico key?
Again I'm not an expert, but I do want to know if this is purely marketing hype or if there's some security to Yubikey and friends that I'm not aware of.
Also pardon me if I confused two-factor as the Google Authenticator app. Too many "factor" terms get a bit confusing after a while.