Live data from Hacker News

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

fidoalliance.org

351–360 of 525 posts

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

#351
post #157
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.

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

I use the "multiple security keys" approach, and the biggest problem is keeping track of which keys are registered with which services and making sure the list is up to date. A few examples of situations where this is a problem:

1) I don't keep all of my keys on my person, so if I want to sign up for a service when I'm not at home, I have to remember to go back and add my other keys at a later time. If I wanted to, for example, keep a backup key in an offsite location such as a safe deposit box, this would be even more painful.

2) If I lose a key, I need to go and change every service to deactivate the lost key and add my replacement key. This is both time-consuming and error-prone, as it requires me to keep a full list of providers that I use keys with somewhere.

3) Some providers do not even allow you to register multiple keys.

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

#352
This is huge! It sounds like they're finally going implement cross-device synced credentials; a move I've been advocating now for the last two and a half years[1].

Widespread support for this feature is, in my opinion, the last thing needed to make WebAuthn viable as a complete replacement for passwords on the web.

The white paper is here: https://media.fidoalliance.org/wp-content/uploads/2022/03/Ho... Seems like they announced this back in March and I missed it somehow.

[1]: https://hn.algolia.com/?query=ajedi32%20webauthn&type=commen...

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

#353
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…

The proposal here is using iCloud Keychain, leveraging the secure enclave. The only catch (for some security-minded, a bit one) is that iCloud Keychain acts similar to a resizable HSM cluster.

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

#354
post #140

I've resisted switching to a hardware key because I know that I'm going to break it, and that seems like a huge pain in the ass. I really want to be able to make a couple of backup keys, or maybe put another way, I want to be able to put the private key on the device myself, I don't necessarily care that the key is generated on the device and never leaves the device. I don't care if that slightly reduces my security…

Has anyone tried a Ledger or Trezor device for something like this? Your FIDO U2F private key is deterministically generated [0] based upon your seed phrase, which you can backup, and restore on other devices. [0] https://www.reddit.com/r/ledgerwallet/comments/udzx1c/ledger...

I have a Ledger as a backup key. Keyword is backup since it's less convenient to use than a Yubikey due to needing to put in a pincode first. Though that could be a security feature in and of itself.

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

#355

Earlier quoted context omitted.

Yes but what the OP is saying is that the TPM does not store the encrypted passkey, rather, the passkey is wrapped with this TPM's public key by another TPM that already trusts this TPM, so this TPM can import a passkey that's been wrapped with its own public key and store it unencrypted. See Apple's circle of trust: https://support.apple.com/guide/security/secure-keychain-syn...

I understand that, but that's not supported by any current standard as far as I know. We'll need a new TPM standard for this, which probably also means it will take years before every device supports this feature as modern computers can easily last five to seven years if you replace the batteries and don't cheap out. FIDO needs something that works now, or maybe tomorrow.

Agreed, and that's why I say in my original comment that I don't see it happening in the short term. If we had something that worked now or maybe tomorrow and was acceptable, it would simply be virtual authenticators; an authenticator implemented entirely in software. There's no practical reason why password managers like 1Password can't do that beyond attestation which nobody checks anyway. But in the end, I don't see the big three participating in sharing. The threat model changes so much that especially for Microsoft (in cell phones) and Google (in desktops) that means trusting an adversarial OS they have no control over

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

#356
post #38

I've resisted switching to a hardware key because I know that I'm going to break it, and that seems like a huge pain in the ass. I really want to be able to make a couple of backup keys, or maybe put another way, I want to be able to put the private key on the device myself, I don't necessarily care that the key is generated on the device and never leaves the device. I don't care if that slightly reduces my security…

You just register 2-3 keys. It's not so bad.

AWS has entered the chat.

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

#357

Earlier quoted context omitted.

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…

Let me be more specific, this should work in apps not just the browser and should work with my logging into my laptop in the browser and leveraging my phone as a FIDO "key".

> This should work in apps not just the browser

Apple, Google and Microsoft all have native API variants of the Web Authentication API. These typically use entitlements requiring authorization back to a website. This means e.g. a Twitter application could leverage the same authenticator registrations as twitter.com, leveraging both platform and roaming security keys.

>... and should work with my logging into my laptop in the browser and leveraging my phone as a FIDO "key".

The press release details this commitment; for instance, I can use an Android phone to log into a website on my Mac. An example of such an option should be visible on all shipping desktop Chrome browsers if you do a Web Authentication registration or authentication request (I believe unfortunately currently titled something like 'Add an Android phone'). On the Apple side, being able to leverage this is currently sitting behind a developer feature toggle.

One can hope that this will be extended to say the Windows platform itself - at that time, I would expect be able to use my iPhone or Android phone to log into any Windows machine on an AAD-backed domain.

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

#358

So their vision of the future is that to do anything online, one MUST have a phone (ahem, portable wiretap)? And they're going to be keeping my secrets for me, for my own good? I'm not sure I'm down with any of that.

My vision of future authentication (shared by colleagues in security) is based in strong hardware credentials and additional layer-7 context about identity, device and location. Basically, more identification of you and your browser using cryptographically-guaranteed and immutable events. It is actually the deprecation of passwords altogether and generally moving the trust boundary away from the control of the user e…

I don't know if you're being sarcastic, but your vision sounds like a nightmare and not very far removed from Gattaca.

> moving the trust boundary away from the control of the user entirely. I also don't enjoy it, but it would solve a lot of current problems we see in information security.

Every despot throughout history has noted that freedom can be traded for security, but I thought that most of us would agree that freedom is more important.

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

#359
post #280
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 think the whole point of HSMs is that you can’t back up (read: exfiltrate) the master secrets. Having said that, on certain Yubikeys you can store PGP keys on them, and put the same secret key on several different Yubis. If you’re relying on a hardware key it’s probably a good idea to have a backup key and make sure both are registered with whatever system you’re accessing. LastPass and GitHub at least support addi…

> I think the whole point of HSMs is that you can’t back up (read: exfiltrate) the master secrets.

You're getting it backwards though. You are right that the whole point of an HSM is to not leak secrets when connected to a compromised computer. However there's nothing wrong with a HSM device that can be initialized with a "seed" of your liking, as long as that initialization step is done in a fully offline / airgapped way.

Ledger (whose CEO was, before creating Ledger), one of the member of the team working on the FIDO specs, make a "hardware wallet" for cryptocurrencies that can run a FIDO app. And it's totally possible to initialize the seed of your liking for your U2F device.

Now I did test this a while ago (out of curiosity) and it all working but I'm not really using it atm: I don't know where it's at regarding the latest FIDO2 specs.

But the point is: what GP asked for can totally be done.

I understand some may want to move the goalpost and say: "ok but then the problem now is not losing your piece of paper where you wrote that seed". But that is another topic altogether that does change nothing to the fact that you can have an HSM used for U2F that can be backed up.

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

#360
post #314
post #290

Earlier quoted context omitted.

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.

Depending on how it's implemented it could still use the same mechanism, couldn't it? (genuine question) For me the question is if this is a webauthn thing in general or a security key thing (to include the domain in the challenge to prevent phishing)

The article specifically discusses auth via app, but if it's involving the FIDO alliance, it'd be weird to exclude hardware keys, I guess. I still don't like the idea of going single factor, but if it's with a hardware key, I can see it being better than with an app since it has to directly interact with the process itself.

But, of course, if this is optional, I still have to reference the end users. I'm willing to pay for an authentic FIDO key, which can be a tad costly. Your typical user might be more inclined to go for a cheap one that does enough to get into the account, and may not be trustworthy, or would prefer not to do it at all.

Post reply on HN