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

321–330 of 525 posts

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

#321

Post by lxgr »

vlan0 wrote: post #72
throwaway52022 wrote: post #35

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…

>my threat model is me leaving my key in my pants pocket before putting it in the washing machine. "YubiKey Survives Ten Weeks in a Washing Machine" I think you'll be safe! :) https://www.yubico.com/press-releases/yubikey-survives-ten-w...

While I'm generally a fan of YubiKeys too, I've had one break without warning. Backups are highly recommended – you can lose them too, after all.

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

#322

Post by adam-p »

throwaway52022 wrote: post #35

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…

I killed a Yubikey in my pocket (without washing) after four years. Get two and keep the backup safe. https://adam-p.ca/blog/2021/06/backup-yubikey/

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

#323

Post by blibble »

ChikkaChiChi wrote: post #283

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 est…

U2F/FIDO2 are immune to this problem as the magic exchange requires the origin hostname to decrypt/verify the remotely stored blob

wrong origin? can't work at all, ever

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

#324

Post by lxgr »

xur17 wrote: post #140
throwaway52022 wrote: post #35

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...

At least Ledger actually does support U2F as an installable application, but that's the predecessor to FIDO and has some weaknesses in comparison. I'm also not sure whether WebAuthN supports legacy U2F authenticators without the browser performing some protocol translation.

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

#325

Post by blibble »

jeroenhd wrote: post #263
dane-pgp wrote: post #232

Earlier quoted context omitted.

> Laptops and modern computers also contains a TPM The root of trust for which extends to who knows where, and you're not allowed to look at the source code or learn how it works because that would threaten Hollywood's profit margins. We're basically building a system of DRM for access to human beings, and making the whole world dependent on these unaccountable entities.

TPMs allow for arbitrary key storage by the operating system. They're not necessary for DRM. In fact, I've wiped my TPM several times to upgrade the firmware and I've had no trouble playing DRM content whatsoever. Technologies like Intel's management engine and SGX or their AMD/Qualcom/Apple counterparts are definitely problematic for user freedom in the way they're implemented. However, the TPM system itself is quit…

> Secure boot with just the MS keys is quite silly and ever since that one version of Grub could be exploited it's basically useless

this isn't true: there's a hash blacklist which is (supposed) to be regularly updated by your OS update mechanism

windows update does it anyway

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

#326

Post by ChikkaChiChi »

blibble wrote: post #323
ChikkaChiChi wrote: post #283

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 est…

U2F/FIDO2 are immune to this problem as the magic exchange requires the origin hostname to decrypt/verify the remotely stored blob wrong origin? can't work at all, ever

Thanks you for your response. I'm going to read up more. I wasn't aware this was a feature.

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

#327

Post by lxgr »

michaelt wrote: post #65
vngzs wrote: post #38

Earlier quoted context omitted.

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

Eh, retrieving a key from off-site storage every time you open a new account is a pretty big inconvenience, even for a security enthusiast.

That's exactly why FIDO [1] and WebAuthN [2] are moving towards a concept of backup-able/cross-device-sync-able authenticators.

That is arguably less secure in some contexts, but there are workarounds, and I do see the point that for most services, availability/key loss recovery is as much of a concern as is security.

[1] https://fidoalliance.org/multi-device-fido-credentials/

[2] https://github.com/w3c/webauthn/issues/1714

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

#328

Post by mmis1000 »

lxgr wrote: post #308
mmis1000 wrote: post #304

Earlier quoted context omitted.

I think FIDO is not meant to be backup at first place. It's more a derived key exists to authenticate certain device safely without being stolen to authenticate other you aren't expected. Make it easily backupable actually defeats its whole purpose if it is intended to be used this way. And for service that actually want it to be used as major key. I think they can just make the one authenticated able to authenticate…

At least the WebAuthN standard seems to be moving in a different direction [1], which is also surprising to me. In a nutshell, it will be possible for relying parties (i.e. websites) to detect multi-device/backup capable authenticators if required, but disabling multi-device functionality would require a very explicit opt-out, not an opt-in, on the relying party's side. [1] https://github.com/w3c/webauthn/issues/1714

That seems to make fido just a non human readable/rememberable account/password. A somewhat downgrade from original hardware enforced implementation. But also make it more usable to majority of people, because keep something without losing it is just a pain to many people(where is my fxxking key goes again?). And it is still 1000x better than people using same password on every website.

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

#329

Post by blibble »

jeroenhd wrote: post #307
sdfgdfgbsdfg wrote: post #279

Earlier quoted context omitted.

It won't, at least not in the short term. For that to happen trusted platform modules would need an api to export a private key wrapped with a certificate signed by (none/one/all/a quorum) of members in the circle of trust and itself. This will need standardizing. Only apple has implemented it so far because it has total control of their ecosystem. I think for Windows and Chrome to work like this, they'll need to sta…

I think the first iteration of this system will definitely receive the synced key material in RAM. It's possible that the TPM spec will be updated to allow for loading pre-encrypted data into the TPM store as a response to this. Alternatively, existing secure computing systems (SGX/TrustZone) can also be used to decrypt the synchronised key relatively securely.

TPMs don't generally store encrypted data (bar their master key)

instead they wrap/seal everything instead with a layer of crypto, then you can pass that wrapped object around as much as you want, only the TPM can unseal it

a TPM could easily be instructed to seal an internally generated secret with additional escrow keys for MS/Apple/...

that plus remote attestation could make it so you can never see the key in the clear

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

#330

Post by withinboredom »

lxgr wrote: post #312
_vdpp wrote: post #280

Earlier quoted context omitted.

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…

You'll need to generate the key on a less secure host to do that, though, which partially defeats the purpose of a hardware key in the first place. As far as I understand, "real" HSMs (i.e. the expensive, rack sized type of security key) sometimes offer the ability to export their root key to other models by the same manufacturer using a specific ceremony. Arguably this also significantly weakens the security of the…

You can generate the keys inside the yubikey. Then just have two keys instead of a shared key. That’s actually better IMHO since that allows you to revoke one of you lose it instead of having a compromised backup.
Post reply on HN