The Yubikey Is the Digital Seatbelt We Need
zagaja.comNo, it's not. We need less shoddy practices to develop software, e.g. mandatory 4-eyes process for security-critical changes, thread modelling, and maybe more Hardware Security Modules that encrypt critical information.
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.
> People already guard their smartphone well.
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.
Amen: TOTP should be on a device with a much much smaller attack surface and supply-chain vulnerabilities.
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.
The banks used to hand out key response generation devices for that. No interface at all but the buttons. There even was a paper version where you scratched to get the key.
Like, it was way better.
In the EU these hardware keyfobs are now forbidden for banking because they are considered less secure than app-based 2FA. The reason is that an app-based confirmation gives you the opportunity to review the transaction you are confirming; they can display "Are you sure you want to send 19.99 € to website.com with payment description 'subscription'?".
This is false.
I use a hardware thingy that I put my Dutch bank card into that generates numbers for logins and purchases. I have the option of using an app or the hardware card reader.
I use a one time generating password hardware keyfob to login to the Dutch Belastingdienst. They require it and I don't think there is an app I can use for this purpose.
If it requires a smartcard I assume this is a different protocol, CAP. The introduction to this paper https://www.researchgate.net/publication/355241124_PSD2_Comp... (not mine) explains the system a little: the old hardware tokens in fig. 1 and 2 are those that cannot be used anymore; I assume you have something like the device in fig. 4?
I agree.
Danish banks, because they use the national MitID authorisation, accept MFA via app, code generator, or a chip device:
https://www.mitid.dk/en-gb/get-started-with-mitid/mitid-auth...
All Dutch Banks are moving customers to their apps now.
There's a DigID app that I use for the Belastingdienst (and all other overheid things), I don't have a OTP keyfob at all.
You could have a keyfob to identify and app to confirm.
> In the EU these hardware keyfobs are now forbidden for banking [...] an app-based confirmation gives you the opportunity to review the transaction you are confirming;
I'm confused, that seems like it confuses two independent aspects:
1. Whether the TOTP code comes from a fob-device versus a phone-device.
2. Whether some interactive interface you're using gives you a chance to see/confirm what you're about to authorize or not.
A phone app can lie to you about the transaction you're about to authorize regardless of whether the TOTP code was transcribed from an external device, transcribed from another app on the same phone, or auto-filled by itself.
This assumes that the banking app receives push data about the transaction by the bank, and simply has an "approve" button A simple 2FA app like Authy/Aegis that produces a number has the same problems as the keyfob.
The threat model is: malicious actor posing as the bank website, but legitimate keyfob or legitimate app. With the keyfob, the website intercepts a valid password and a valid 2FA code; with the app, nothing happens because it doesn't receive push data from the true bank.
I hope it is more clear now!
> with the app, nothing happens because it doesn't receive push data from the true bank.
I don't see how that feature matters to a man in the middle attack during logon, since:
1. User opens web browser at a phishing site, which is masquerading as their bank, and starts the login process.
2. Phishing site interacts with bank.
3. Bank sends push-notification to the phone# that's on-file for that user: "Hey, that you logging in right now? Press the Yes button if so."
4. User sees it, expects it, presses the button, and then proceeds to hand over their TOTP and password to the phishing site anyway.
I suppose it might help on a per-transaction basis if the phishing site tries to trigger a hidden transaction, but at that point the app is just a way to streamline: "We sent you a code by SMS, enter that code to confirm the transaction."
The point is that the app displays data on the transaction. If the phishing site tries to trigger a hidden transaction (or modify one that you are entering), you can review amount, recipient, and description _on the app_.
I can unlock and drive my car with my phone and the house has smart locks. What is this keychain you keep mentioning? I know the app but I don't think that's what you mean.
> I'm sure any smartphone-based TOTP will do
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.
You can get as many eyes as you want on all changes. I don't think it will help much. This sort of thing usually happens because of a change in something completely benign, rather than "security-critical changes".
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.
Would branch coverage have helped you here?
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.
Yeah, almost certainly. We had looked into enabling branch detection several years ago, but it had slowed our suite down to the point where we were not sure it was worth it. Maybe worth looking into again.
I do generally like that technique of returning more vetted objects, but I'm not sure that it scales. Our users have close to one hundred different permissions based on the features their admin pays for, having an object for every type seems like a lot. Every combination of types is straight out.
The original issue I was talking about I don't think could have been helped. It was an encoding problem that could have potentially lead to XSS injection with a very specific set of GET parameters. I was frankly surprised that the PEN testers managed to find it.
Not a hot take at all, for anyone who has worked with securing code.
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.
> We should be putting less trust in software.
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.
TOTP is trivially phishable.
Code security is orthogonal to end-user authentication methods.
So, wrong on every count.
I have a yubikey. It's okay but I don't take it with me. When I'm out I use my phone with a MFA app, and would never tie my MFA to a hardware dongle that is likely not to be on my person when I need it.
> It's okay but I don't take it with me.
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.
The problem is that you need at least hardware tokens, one on you and one in a safe place as a backup. And I can't justify the cost of that.
I wasn't able to justify the potential cost of not having them.
> People already guard their smartphone well
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.
> 4-eyes process for security-critical changes
Sounds good on paper, but not practical. Who decides what is a security-critical change?
>And if you need a second factor, I'm sure any smartphone-based TOTP will do
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.
... Until you drop your phone and it breaks. And now you can't set up a new phone because you need to tap the notification sent to your old (now broken) phone in order to set up your new phone.
I've already had this happen, which is why I use hardware keys now, and a backup phone.
Do you mean, you don't print these rescue codes which every 2FA thing keeps nagging you about? You don't have a printout in your wallet, or in your folder with important papers? Not even as a secure not in your password manager?..
Nope, because I was grandfathered into it when Google switched it on for everyone without saying anything. You can still access gmail and such; you just can't set up any more devices without having some kind of 2fa.
Now I have a hardware key. I wouldn't dare keep rescue key codes (which can't be revoked) in my wallet.
Can't you just use them to revoke them?
You can't revoke them if the paper is in the wrong hands, and you don't have a normal access to your account. (Well, they are much like a password in this regard.)
It's just different risk profiles. Your biggest risk might be to drop your phone and lose all the 2FAs in a Google Auth app. Or your biggest risk might be losing your wallet to a thief or robber who is going to hijack your accounts.
I think the chances of the kind of person who steals your wallet also being able to leverage pilfered two-factor authentication codes to hijack your accounts is almost zero.
Yubikeys are useless when someone can reset your password or 2FA using personally identifiable information that was just leaked. A lot of us who practice good security will be PWNED through large scale data leaks. Whenever I sign up, I sign up with fake information, and so should you. Most services will not KYC you, so just lie.
As someone who recently dropped his phone in salt water can attest, it was pretty easy to reset my access for 8 of 10 of my 2FA accounts.
agreed, this only works if there are not "workarounds" or non-trivial ways to recover your account if you lose your yubikey.
Bought yubikey on a sale a few years ago. Not usable for mobile in that model (4?) (but I knew it in advance of course). Then found out that most of the sites don't accept it in the Firefox, only in the Chrome and its clones. And so it is collecting dust somewhere in my old apartment.
I had similar issues with Safari a few years ago. The situation has vastly improved as most modern sites detect for FIDO2 support instead of just scanning your browser agent.
They’ve natively worked in Firefox for a couple of years now.
The fact that there are other ways to circumvent 2fa highly depends on companies practices. Using fake informations is a good start but even without fake infos I still am trying to regain access to the majority of my 2faed accounts since last December
BEST AGENCY TO RECOVER LOST OR STOLEN CRYPTOCURRENCY
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.
The YubiKey is not the single answer for this problem. The right approach will depend on the specific needs of each user.
More importantly, MFA needs to be more widely adopted and the account recovery process needs to be hardened.
Related:
EUCLEAK Side-Channel Attack on the YubiKey 5 Series
the timing hurts
Nope. It’s an add-on, but you can lose them. I am a bit flabbergasted that corporates are now handing them out like candy, but only one to a user. And if they lose them, they can’t even log in to request another.
I don't know which company you are talking about, but every company I've worked at always had a two Yubikey policy.
My large company certainly doesn't. Oh, don't get me wrong - I have two, but they're for accessing different resources! If I lose one, I lose access to those resources until I can get a new one shipped to me. Can't buy your own either - not that I'm complaining about that.
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.
You should probably bring it up. I guess they figure if you only use it with company accounts that IT can always fix it and get a new one to you. That would dissuade you from using it for personal accounts. Not my own opinion, just trying to figure out how the bean counters think.
Agreed, folks will need at least two.
Yeah I’m not super familiar with Yubikey but can’t you get a backup one you can hide away in case you lose your “main one”? I really don’t like single points of failure like what you are pointing out. I think my odds of losing my device are far higher than getting hacked with plain old TOTP or passkeys. All my financial sites have 2FA turned on or I would kick them to the curb.
I did have one, it was something like 20 steps to get it setup - a bit of a pain.
What exactly did you do that you needed 20 steps to setup a YubiKey??
Yeah if any service supports it - it's usually pretty seamless process to set it up.
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.
Yubikey will never prevent your data from being leaked. They didn’t crack your password.
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.
>Have random, unique passwords. Use a password manager. Done.
Still vulnerable to phishing, and that's where Yubikey & U2F can help.
> Yubikey will never prevent your data from being leaked.
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.
I use my yubikey to lock my keepass database
I prefer user side SSL certificates.
Does a client-side certificate have a button which you must physically press to confirm the action?
It's very important that some things wound not happen automatically.
What do you mean? I think that you mean giving token/passwords to the browser. And by pressing the phisical button you ensure that you don't give it to another web site.
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.
I don't think that's right. Client side certificates can be used with any domain. There isn't even an X.509 attribute to represent such a restriction. No major TLS or certificate store implementation I'm aware of provides any out-of-band way to restrict client cert domains either, not even the PKCS11/Cryptoki hardware interface.
If you have client certs installed and ready for use, especially with automatic selection, a rogue but otherwise "trusted" server can request your certificate by its issuer DN and, even though you may not directly provide any other information, any details about your identity present on the certificate can then be seen by that server.
Even so, thanks to the underlying security model of TLS, giving your cert to a rogue server still doesn't directly open up any confused deputy or MITM risks though, as far as I know, which is more relevant to the comparison with Yubikeys. Certificates, even client certificates, are meant to be "public", and the mere possession of one proves nothing; no certificate should be trusted until the party presenting it can prove it has the associated private key.
Corroborating SO answer: https://serverfault.com/a/1086000
I mean a separate physical device, like, well, a Yubikey, that can't be automated away due to some vulnerability or UI spoofing. A browser keeps your client-side certificates. A browser is a hardened, but also an incredibly complex piece of software. Chances that an exploit would let coax it into activating a particular client-side certificate without your noticing are pretty slim (hopefully), but for a hardware key which is simpler and even more hardened these chances are lower still.
That's basically what FIDO2 is.
An even better analogy would be food safety enforcement for large food processors: not wearing a seatbelt makes the author’s proposal seem like it’s about you, when it really is about well-needed criminal penalties for FooCoGotPwned Ops (where FooCoGotPwned isn’t in tech, health, or finance.) Otherwise, like listeria in your liverwurst, it’s only a matter of time until you get hacked.
The only current remedy is a class action lawsuit which will eventually give you a pittance after many years, and it’s pathetic.
https://ninjalab.io/eucleak/ the timing lol
Extraction of the ECDSA secret key of Yubikey 5 series FIDO devices