The one thing I don't understand with Yubikeys: doesn't leaving them plugged in at all times in your computer (which the form factor highly encourages you to do) completely defeat the purpose?
Pressing YubiKeys
171–180 of 241 posts
Re: Pressing YubiKeys
#172Google won’t let you setup 2FA without adding a phone number which kind of sets you up for sun swapping attack by design... My biggest beef is lack of NFC in MacBook. I wan’t a key in card factor because who the hell has keys these days. Maybe add hardware button on the card. It would work on on mobile and laptops. Banks could use their own credit cards for logging in...
If you've got adversaries doing a sun swapping attack you are in a Rick and Morty episode not the real world. I can't swear Google has never known one my phone numbers in the many, many years I've had an account, though they don't have one recorded now. However I can tell you with certainty I have three WebAuthn authenticators, and no SMS-style 2FA authorised on my Google account now.
Try with a new account. Authenticator app option is not there until you add number. Prompt never succeeds until you add number.
Re: Pressing YubiKeys
#173> If you work in tech, you probably have a YubiKey That is a gross overstatement. As someone who works for a pre-IPO startup and been in the bay in various startups for a number of years, I'd hazard that only 5-10% of the engineers had YubiKey, let alone "work in tech". Whether or not we _should_ is another question.
I've never had a YubiKey, but lots of other places use smart cards (ISO 7816) for secure authentication. I suspect they are far more common than YubiKeys or newer tech, especially in the financial industries.
Re: Pressing YubiKeys
#174Nice build but over engineered. You could achieve the same result by taping a piece of aluminum foil, or maybe even a wire to the capacitive sensor and connecting it to ground through a relay. Use the ESP8266 to toggle the relay when you want to simulate a button press.
That violates corporate IT policy which expressly instructs me to touch the key with one of my fingers.
Technically the author is using of their fingers. Wasn’t the model Creative Commons?
Re: Pressing YubiKeys
#175Earlier quoted context omitted.
> the purpose of having a YubiKey Compliance?
I'd hazard saying that the purpose of a YubiKey is to provide two factor authentication. A YubiKey acts as an item, posession of which implies identity. When you allow for the YubiKey to be activated without human interaction, it's moved from domain of posession into the domain of knowledge - identifying party needs to know where to knock, not to possess they key. It's no better than appending the URL at the end of y…
If they made the uri SSL with fixed certs it’s still a “something I have” factor IMO.
Re: Pressing YubiKeys
#176I thought the article was going to be about how there was a serious real vulnerability in the hardware and some remote attacker could spoof the Yubikey being touched.
Then the article turned into a joke.
Re: Pressing YubiKeys
#177The one thing I don't understand with Yubikeys: doesn't leaving them plugged in at all times in your computer (which the form factor highly encourages you to do) completely defeat the purpose?
No, you need to press the button.
In situations where laptop is not under your control, you can remove it.
Re: Pressing YubiKeys
#178Earlier quoted context omitted.
Correct - just like an evildoer who had your yubikey could generate and save a bunch of yubikey key strings, they could also generate and save a bunch of time-based codes for times in the future by changing the host clock. You can use a bidirectional challenge-response between the yubikey and a trusted server - that's what U2F does. But honestly, if an attacker has both your password and physical possession of your 2…
Sure you can! (For yubikey OTP key strings at least) Just have yubikey sign the current time, you're already trusting them to correctly verify the key string. U2F is a different animal though. The question is then: does timestamping the response reduce the attack surface enough compared to the downsides? I'd argue yes since the described attack can offset a failed login and the actual attack after a MITM. Also, it is…
> Just have yubikey sign the current time, you're already trusting them to correctly verify the key string.
By "them" you presumably mean Yubico not the Yubikey. But these OTP strings are generated by the Yubikey, not by Yubico so there's no way for them to be "signed" in this way. The verification process takes place at authentication so that would just tell you the current time, something you already know, it's useless.
> U2F is a different animal though. The question is then: does timestamping the response reduce the attack surface enough compared to the downsides? I'd argue yes since the described attack can offset a failed login and the actual attack after a MITM. Also, it is probably possible to get the time-stamp within the kernel. If your root is compromised you're also done for.
For WebAuthn (and its predecessor U2F) none of this is correct.
The Relying Party (a web site you want to authenticate to) sends a random challenge. A correct authentication in part signs that challenge, so timestamping is irrelevant here, your answers are either fresh or they're invalid anyway.
Because a physical FIDO authenticator is independent from the computer you are not necessarily "done for" if the computer is compromised, unless you've outfitted your computer with a finger to press keys it cannot, for example, press the button on the key, so there is no way for the compromised computer to obtain signatures from the authenticator with the UP (User Present) bit set, and checking UP in the signed response is part of WebAuthn.
Re: Pressing YubiKeys
#179Earlier quoted context omitted.
AWS, Twilio, PayPal, Coinbase, Gusto, ...
Holy crap. I've avoided buying a U2F/FIDO2 device (eg. YubiKey) for a few years thus far, as I'm "happy enough" with TOTP. I know the differences in terms of implementation/security, but not enough services even offer TOTP, let alone the U2F/FIDO2 protocols. It's not worth the investment right now for how generally unsupported it is. Do most services that support such devices really only support a single key/device?…
I have a pair of hardware FIDO authenticators, and my phone and laptop are both platform authenticators.
I have personal accounts with Google, GitHub, GitLab, Facebook, and DropBox that use at least two of those four authenticators. I also have Login.gov (US government) and Gov.uk Verify (one of two UK government authentication systems, hooray for needless duplication)
Most of them offered one-time recovery codes which I hand wrote in a book of one-time recovery codes, but without fetching that book I can't tell you it was all of them.
At my previous job I used a physical authenticator with AWS and that was indeed restricted to just one authenticator, on the other hand there's an account "administrator" for that AWS account so if you lost your authenticator the admin can get you back in and I assume larger companies have multiple people in the administrator role.
The WebAuthn specification explicitly says that Relying Parties (ie web sites) should support multiple keys.
And yes, if you lose access to all methods of authentication in some cases you lose the account. I believe GitLab explicitly flagged their intent to act this way for accounts that don't pay them money, and I would prefer this. As I wrote back then, if it's not worth an hour of my time to somehow try to prove my identity to you after locking myself out of your service (which if I'm not paying you, it probably isn't), then I don't want it to be worth an hour of some social engineer's time to steal my account.
Re: Pressing YubiKeys
#180Earlier quoted context omitted.
You use the backup keys the service gave you when you enabled 2FA.
Those backup keys defeat the entire purpose of 2FA and are like storing passwords in plain text. It only takes 1, maybe 2 of those codes for an attacker to add another security key to your account for future unlimited access. Supporting multiple keys is a better solution.
Supporting multiple keys is a good idea but it solves a different problem. People want peace of mind.
Backup codes are not like passwords in at least two important ways:
* The site picks them, not you, so they're random nonsense different for each code, rather than inevitably being password1234 and being the same on Instagram, Twitter and your bank account.
* You don't need them usually, so there's no reason you'll have them to hand, which then makes it harder to steal them. Even for a social engineering attack, you increase the friction because now to help the attackers a user needs to go find their backup keys which is a hassle.