And if you need a second factor, I'm sure any smartphone-based TOTP will do. People already guard their smartphone well. No extra key fob needed.
Keychain too.
Something irks me about concentrating all access management on a device that people also use for tons of commercial, data slurping apps and games. Banks, national governments, shops; they all want me to use their app as 2F. To me it seems precisely the opposite: the phone is not a good place for this.
This was many years back, but I remember searching to see if there was some kind of hardened not-a-phone appliance, without much luck.
No it won't. Like the article states, I also believe that phishing resistance is a critical property of 2FA systems. This is something that TOTP will never be able to provide.
We don't need Yubikey the brand, but we do need security keys (i.e. FIDO) as a concept.
We recently had a pretty major vulnerability exposed by a PEN test (thankfully) that was caused by a single misplaced NOT ! operator in a pretty simple function, maybe 20loc with 100% test coverage as counted by line.
The problem case was untested because while tests touched 100% of lines, not all combinations of paths through the code were tested.
The code had been written by myself about a year ago, and reviewed by four seasoned developers, none of whom spotted the issue.
How many thousands of eyes are on OpenSSL and yet major world ending vulnerabilities still crop up?
This might be a hot take, but you can make the process as painful as you like but at the end of the day, building secure software is nigh impossible. We should be putting less trust in software.
And I think one of the approaches that helped me to write safer code is to parse, and not validate.
That way drastically limit the situations we can get into where we forget to validate certain conditions.
e.g. you have a User struct, and you want to do an action which requires you to validate whether the user is an admin.
2 options here
* validate whether the user is an admin (which could happen multiple times when you're invoking distinct functions as part of a workflow)
* parse the User into an AdminUser. If the user is an admin, the function will work, and then you can pass on your new struct into places that require an admin. If it fails, the user is not an admin. Now you have merged all your checks into 1 place.
SWEs simply aren’t trained to deeply examine code and the side effects of it being pressured by skilled attackers.
2+ LGTMs reduces the change of a security issue making its way in, but no amount of expensive “more eyes” will eradicate bugs.
This is the conclusion I've come to as well. Nothing critical should be solely software dependent. Software will fail and critical systems should be able to function without it.
Code security is orthogonal to end-user authentication methods.
So, wrong on every count.
Sounds like that is the problem? I have mine on my keyring. (and have a backup in a safe.)
> would never tie my MFA to a hardware dongle that is likely not to be on my person when I need it.
The solution is to have it with you.
You guard it well, your carrier barely even tries to guard your number from being stolen. Once you have that you can get into Apple account SMS auth/iCloud passwords and keys.
Sounds good on paper, but not practical. Who decides what is a security-critical change?
No, it won't, because TOTP doesn't protect against phishing, which remains a threat even if randomly-generated unique passwords are used. That's what U2F protects against, is phishing.
I've already had this happen, which is why I use hardware keys now, and a backup phone.
I recommend Hack Recovery KEVIN M HACKER to anyone who needs this service. I decided to get into crypto investing and lost my crypto to an investor late last year. The guy who was supposed to manage my account was a fraud the whole time. I invested $180,000 and at first my read and profit margins looked good. I got worried when I couldn't make withdrawals and realized I had been tricked. I found some testimonials that people had to say about Hack Recovery KEVIN M HACKER and how helpful it was in getting their money back. I immediately contacted him via. Email: kevinmitnick100@hackermail.com, Telegram @Kelvinmhacker or WhatsApp via: +1-256-956-4498, and I’m sure you will be happy you did.
More importantly, MFA needs to be more widely adopted and the account recovery process needs to be hardened.
EUCLEAK Side-Channel Attack on the YubiKey 5 Series
Of course, since one of the keys protects access to resources that can only be accessed from a special laptop, it lives there, and is hard to lose, although that may also reduce security since it means the laptop and key are always together.
Now maybe if you're talking about using it for SSH, then it gets slightly more tricky depending on your config. Then again, it's definitely under 10 steps to set that up as well.
But a random, unique password prevents further harm. They can’t get data from another site just because they hacked this one.
Have random, unique passwords. Use a password manager. Done.
Still vulnerable to phishing, and that's where Yubikey & U2F can help.
That depends on how your data is being leaked. Of course it does not stop the service provider from leaking your data (intentionally or unintentionally). It protects you from phishing attacks.
> Have random, unique passwords. Use a password manager.
Sure. These are still good practices even with a yubikey.
It's very important that some things wound not happen automatically.
Cline side certificate works only for the given specific domain and it automatically recognizes you. I forgot the specifics but it only works for a specific domain. You cannot use it for another domain even if you want.
The only current remedy is a class action lawsuit which will eventually give you a pittance after many years, and it’s pathetic.
Extraction of the ECDSA secret key of Yubikey 5 series FIDO devices
