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

331–340 of 525 posts

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

#331

Post by lxgr »

zozbot234 wrote: post #188
gazby wrote: post #172

Earlier quoted context omitted.

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…

Software ("virtual") implementations are already possible in WebAuthn. It's up to the service whether to allow enrollment via a software authenticator; most services will want to allow this, seeing as it's still way more secure than ordinary username/password.

A much more secure way of doing this is to use the platform's/OSs most secure way of storing private keys, which in many cases is hardware (Secure Enclave on iOS, TrustZone or "real" secure hardware like Titan M on Android, TPM on Windows/Linux).

This is already supported by many browsers (unfortunately Mozilla/Firefox are dragging their feet on this one [1]) and gives you exactly the user experience you want.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1536482

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

#332

Post by snowwrestler »

alberth wrote: post #21

Dumb question: why are biometrics being used to replace the password , shouldn't the biometric replace the username ?

The short answer is that you can lose a biometric but still be you. So a biometric is not a username.

Also, the biometric does not actually replace a service password in this instance, it just helps authenticate you locally to a device. The key on the device is what is actually replacing your password.

Depending on the device or settings you choose, you don’t need to use biometrics at all if you don’t want to.

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

#333

Post by withinboredom »

lxgr wrote: post #309
sheerun wrote: post #298

Earlier quoted context omitted.

A backup key could have ability to reject original one, problem solved...

How would that work in practice? Key/certificate revocation is notoriously hard.

With GitHub, you just remove it from your account. For 2fa, same story.

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

#334

Post by lxgr »

mjevans wrote: post #310
throwaway52022 wrote: post #199

Earlier quoted context omitted.

For web apps/services, the browser needs to be involved here too, right? (And maybe the OS?) How can I tell Chrome on my desktop to use my "software token" instead of Chrome looking for a hardware token over USB or finding it via NFC, so the remote service can ultimately interact with my (virtual) token? (I don't even want to think about how to tell Mobile Safari on my iPhone how to find my key) EDIT: My ideal setup,…

I do NOT want to use my phone. It cannot be considered to be a secure device given the 'network' baseband control chipset will never be owned by the phone's buyer and has full access to the device.

Storing your keys in secure hardware on a phone is almost certainly more secure than storing a key in software on your desktop hard drive.

If you don't trust your hardware, it's almost always game over. Desktops have devices running dubious firwmare as well, but at least with a hardware key store, the window of compromise ends at the time you update – a stolen key stays stolen forever.

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

#335

Post by jeroenhd »

blibble wrote: post #329
jeroenhd wrote: post #307

Earlier quoted context omitted.

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…

As far as my understanding goes this sealed secret is device specific and connected to the TPM master key. That would mean you could pass it around, but you'd need to have the blob on the device itself to actually use it.

The problem is that you need private/public key pairs that are synchronised across devices for FIDO to work properly cross-device. When you register an account on your phone, you need that account key on your desktop to use it there, and that's nearly impossible without some kind of key sharing mechanism.

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

#336

Post by lxgr »

pat2man wrote: post #171
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.

Ledger ( https://www.ledger.com ) supports FIDO and lets you do backups. You really need a screen to do it correctly, otherwise there is little point in having an external device.

This might be true for cryptocurrency transaction initiation, but in the WebAuthN model, what's the benefit of having a screen?

The result of a WebAuthN challenge procedure is almost always a session cookie (TLS channel binding if you're really fancy), so the only thing that an authenticator could display on your screen is "do you want to authenticate as user x to website y", which arguably does not add that much value.

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

#337

Post by jeroenhd »

blibble wrote: post #325
jeroenhd wrote: post #263

Earlier quoted context omitted.

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

Is there a way to list this blacklist? I have several computers which haven't received updates in years and I strongly doubt that the internal blacklist has been updated.

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

#338

Post by lxgr »

withinboredom wrote: post #330
lxgr wrote: post #312

Earlier quoted context omitted.

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.

Ah, sure, if your use case allows registering multiple keys that is indeed a good way to solve it. Unfortunately that's not always the case (as pointed out in other threads).

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

#339

Post by avianlyric »

sph wrote: post #183
avianlyric wrote: post #152

Earlier quoted context omitted.

The expectation is that you also have “something you are” as provided by your devices biometric authentication. The standard allows for service to demand that the authentication device performs an additional factor authentication. Which is usually either a PIN or biometrics, and your device attests to doing this during authentication. So then you have two complete factors “something you have” (your phone) and “someth…

But I'm responding to GP that said biometrics are a username, not a secret, which I agree. I'm not sure something you are counts as a security factor.

> But I'm responding to GP that said biometrics are a username, not a secret, which I agree.

If you were sending an actual copy of your biometric data to the remote authentication service, then maybe you could make that argument.

But that never happens, no FIDO biometric device sends a biometric fingerprint that could be reproduced by a different device. The device authenticates you with biometrics, then uses that data to unlock a private key, which is then used to answer a challenge-response request from the authenticating service.

If you don’t the device, then it’s pretty much impossible for you to correctly answer that challenge-response, despite being in possession of the biometric features that device would use to authenticate you.

So you can’t use your biometrics as a username. Because the device measuring the biometric data pushes that data through a mono-directional, randomly generated (at device manufacture), hash function, that exists within that device only. Take your biometrics else where (I.e same device type/model but different physical object), and you’ll get a different output even with identical inputs. Which would be a pretty useless username.

> I'm not sure something you are counts as a security factor.

You should take that up with NIST then: https://www.nist.gov/itl/smallbusinesscyber/guidance-topic/m...

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

#340

Post by _vdpp »

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…

Yeah, for the paranoid you’d have an air-gapped box with your PGP tools on it that you’d plug the hardware key into for setup.
Post reply on HN