[deleted]
The Yubikey Is the Digital Seatbelt We Need
41–50 of 73 posts
Re: The Yubikey Is the Digital Seatbelt We Need
#42Earlier quoted context omitted.
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 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.
Re: The Yubikey Is the Digital Seatbelt We Need
#43Yubikey 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.
Re: The Yubikey Is the Digital Seatbelt We Need
#44No, 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.
>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.
Re: The Yubikey Is the Digital Seatbelt We Need
#45The 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.
Re: The Yubikey Is the Digital Seatbelt We Need
#46Bought 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.
Re: The Yubikey Is the Digital Seatbelt We Need
#47Earlier quoted context omitted.
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
Re: The Yubikey Is the Digital Seatbelt We Need
#48Earlier quoted context omitted.
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.
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.
Re: The Yubikey Is the Digital Seatbelt We Need
#49Bought 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.
They’ve natively worked in Firefox for a couple of years now.
Re: The Yubikey Is the Digital Seatbelt We Need
#50No, 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.
> 4-eyes process for security-critical changes
Sounds good on paper, but not practical. Who decides what is a security-critical change?