Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard

fidoalliance.org

Post reply on HN
Print view View original

281–290 of 525 posts

Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard

#281

Post by _vdpp »

andrey_utkin wrote: post #237
traceroute66 wrote: post #158

Earlier quoted context omitted.

> Are there any FIDO security keys that explicitly support backing up and restoring their master secrets? Why would you need that ? On most services that I use that support FIDO, you can register as many keys as you like. Seems to me that is a much more secure option than to provide a potentially exploitable option of allowing key extraction.

You cannot register more than one security key with *AWS*. Which a lot of devs beg for, for years. Can't find that support ticket URL now.

That’s a pretty big foul. I use a different hardware key plugged into each workstation I use and then some “roaming” keys that I can use for backup, travel, etc.

Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard

#282

Post by [deleted] »

matheusmoreira wrote: post #275
danuker wrote: post #268

Earlier quoted context omitted.

> Passcodes can therefore be compelled if their existence, possession and authentication are "foregone conclusions," the court said in the August 2020 ruling, determining the 5th Amendment's foregone conclusion exception applied in the case. https://www.reuters.com/business/legal/us-supreme-court-nixe...

What if you forget the password?

[deleted]

Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard

#283

Post by ChikkaChiChi »

Why aren't we doing more to validate the identity of the service we are trying to connect to? CAs don't allow me to establish my own personal web of trust. If I connect once to my bank in a method I deem safe, I should be able to store their credentials in an easy to validate way.

That way if I fall for a phishing attack, the browser can CLEARLY indicate to me that I'm encountering a new entity, not one I have an established relationship with.

Concurrently, OSes need to do a way better job of supporting two factor locally and out-of-the-box. To even use a yubikey personally you have to install their software and disable the existing login methods or else you can still login the original way you set up.

While we're at it, browsers and operating systems should actually lock out the second a key is no longer connected/in range. I know smart cards can behave similarly, but this needs to be grandparents level of easy to set up and control.

I would feel much safer with my elderly family having "car keys" to their PC.

Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard

#284

Post by giaour »

snarf21 wrote: post #256
aftbit wrote: post #148

Are there any FIDO security keys that explicitly support backing up and restoring their master secrets? I would love to move from Username + Password + TOTP but my current workflow requires that I am able to regain access to my digital accounts using nothing but a few page paper backup including core service passwords & exported TOTP secrets.

I wish FIDO was built into the phones (enclave) requiring a biometric and passcode. For 99% of users this would be superior to email/password and get rid of a lot of hacks/phishing. It doesn't require extra hardware to buy and simply requires a minor protocol update to have the challenge on a laptop/desktop show as a QR-code (or could be sent via BT). The mobile sends the response out of band to a destination set at…

This should already be supported on most phones: https://webauthn.me/browser-support

Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard

#285

Post by staticassertion »

stingraycharles wrote: post #250
austinbv wrote: post #242

The problem with any key based auth or biometric auth is a user can be compelled by LEO to hand over private keys or open a biometric lock. Passwords are protected by the 5th amendment.

The standard answers for these things is to use both; they’re not mutually exclusive, and for important things you almost certainly want both.

The expansion mentioned in the article is explicitly passwordless.

Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard

#286

Post by danstiner »

gazby wrote: post #172
aftbit wrote: post #148

Are there any FIDO security keys that explicitly support backing up and restoring their master secrets? I would love to move from Username + Password + TOTP but my current workflow requires that I am able to regain access to my digital accounts using nothing but a few page paper backup including core service passwords & exported TOTP secrets.

Just so you don't feel alone with the replies being of the typical variety, I'm 100% with you. The flaws in the "backup token" approach are rehashed constantly but the world keeps turning as though they're irrelevant. I look forward to hardware tokens reaching a popularity level where we see implementations in software and this conversation can be rendered moot. Shout out to Mozilla and Dan Stiner for their work so f…

Thanks for the shout-out!

I wrote that U2F implementation in software because I wanted phishing protection without needing to carry a hardware key. Well, and to learn Rust :) It's certainly a security trade-off to just store secrets in your keychain like I choose to, it is not meant to be a replacement for a hardware key and in fact I have a Yubikey I use when the situation calls for it.

I'd love to use TPM and biometrics to implement U2F/WebAuthn on Linux and have a proper, secure solution. Similar to what Apple has done with Touch ID. But that's no easy task. TPM support is poor on Linux and other options like relaying auth requests to your phone for approval and storing secrets in the Secure Enclave is no easier.

Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard

#287

Post by _vdpp »

bpye wrote: post #217
georgyo wrote: post #59

Earlier quoted context omitted.

It's actually horrible! Even key rotation is horrible! My yubikey is getting to about 10 years old, and I have replacements for it but find it very difficult to switch. It will eventually fail as an things do and it will be problematic. The problem is that I have several dozen accounts connected to it and I don't know all of them. So either I'm carrying and trying multiple keys at all times or not getting into a site…

I’m going to need to work this out soon. I picked up a pair of new YubiKey 5Cs yesterday with their sale. I’ve been using a YubiKey Neo for years for U2F, TOTP and GPG. Moving the GPG key is easy - though I might try using the FIDO2 support in SSH instead. However for every TOTP and U2F key I’m going to have to re-enroll the new keys… It feels like there should be a better way.

FIDO2 with resident SSH ed25519 keys works great, just make sure the OpenSSH client and server versions on all the machines you’ll be using the key on support it. I wish there was a way to sign Git commits somehow using them instead of PGP.

Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard

#289

Post by giaour »

Zamicol wrote: post #176
jupp0r wrote: post #157

Earlier quoted context omitted.

Yubikey recommends a backup key for that very reason. Most providers allow you to register multiple keys.

"providers allow you to register multiple keys" Why isn't my identity just a Merkle root? I don't understand the need to register individual keys.

You'd also need some way to revoke keys signed by the root if a valid hardware key were lost, stolen, or confiscated.

I think Yubico will actually do something like this for large enough customers, though revocation is left as an exercise for the customer. When I worked for AWS, I was issued a couple company YubiKeys, and there was a web portal where I could revoke a token's association with my account.

Re: Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard

#290

Post by bedast »

cmeacham98 wrote: post #262
bedast wrote: post #184

Earlier quoted context omitted.

You're looking at an exploit from a technological point of view, which I expect this community is likely to do. Think of it from the perspective of the average user. I know for a fact if my mom was told by an attacker "if you see an approval request for your account, just accept it" she would do so. It's taken time to train her not to give anyone her password. I've read of attackers with valid passwords spamming logi…

You don't understand FIDO/webauthn/etc. The scenario you describe is impossible. This is the genius - the user is totally cut out of the equation, there is no action your mom can take on phishing-website.com to send the credentials of google.com, because the key will refuse to do so.

What this article is about is authenticating the request with an app on your phone, not a hardware key. This ends up being a device totally disconnected from the device requesting the auth, and neither have to be in the same geographic location unless implemented alongside the spec.
Post reply on HN