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

381–390 of 525 posts

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

#381

Post by Kab1r »

_vdpp wrote: post #362
TacticalCoder wrote: post #359

Earlier quoted context omitted.

> 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 / airgappe…

How is that seed any different from a password then?

For one, it's only ever seen once: during initialization.

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

#382

Post by Spivak »

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.

And probably never will because the official unofficial solution is to use SSO and have your identity provider handle that.

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

#383

Post by tpush »

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.

The baseband CPU doesn't have full access on any decent phone.

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

#384

Post by tialaramex »

lxgr wrote: post #317
tadfisher wrote: post #233

Earlier quoted context omitted.

This sounds suspiciously like PGP subkeys. Having not read into how FIDO works, I'm going to now assume it works by supplying a "public key" to a third party, and the third party authenticates by having you encrypt a nonce with a private key. How far off am I?

Cryptographically speaking it's signing a challenge, not encrypting a value (which would be a public key operation), but generally speaking yes, that's the idea of it! One of the things FIDO adds beyond a protocol for "plain" hardware-generated and stored keys is the idea of attestation, i.e. authenticators being able to express statements like "keys can never leave this authenticator" or "this key requires PIN or fi…

However, you should not require attestation for public services. If you let Jim sign up with his dog's name as a password, but then refuse to let Sarah sign in because her FIDO device wouldn't provide "attestation" you're crazy.

Attestation probably isn't the correct choice for almost anybody, but the cases where it could at least make sense are if you're an employer checking employee authenticators, if you gave everybody a Yubico Fantastic XXV authenticator, you might decide it makes sense to verify the credentials enrolled are from Yubico Fantastic XXV authenticators. But still probably not. On the whole, everywhere I see UIs for managing attestation it makes me a little bit sad, because it's an attractive nuisance. Azure AD for example does this.

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

#386

Post by tialaramex »

lxgr wrote: post #336
pat2man wrote: post #171

Earlier quoted context omitted.

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

The comment you're replying to is about cloning WebAuthn credentials. This is a delicate operation, because you are effectively cloning your entire identity. So yeah, a screen seems reasonable for that purpose.

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

#387

Post by lxgr »

TacticalCoder wrote: post #364
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…

But is that a problem though? I generated my own HSM/U2F keys throwing dice and the seed is basically just one 256 bit numbers. I did have, indeed, to compute a matching checksum (for the scheme I used represented the 256 bit numbers as a list of 24 words, out of a dictionary of 2048 words, where some bits of the last number acts as a checksum). This only needs to be done once. For example by booting an old computer…

> booting an old computer with no wifi capabilities and no hard disk from a Linux Live CD.

By doing that, you are increasing your trusted code base by several orders of magnitudes doing that. This might be fine for your purposes, but in a corporate environment, it might very much not be.

> Then I only need to trust the specs, not the HSM vendor.

You do trust the HSM (vendor) no matter how you use it. Ironically, the more modern a cryptographic protocol is, the more opportunity for surreptitious key exfiltration there is. This could be in the form of predictable (using a shared secret) initialization vectors, wrapped keys and much more.

You also trust an HSM to be more tamper-resistant and/or more hardened against logical attacks than a regular computer, or there would not really be a point in using one in the first place.

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

#388

Post by threeseed »

Nathanba wrote: post #75
jeroenhd wrote: post #26

Earlier quoted context omitted.

If that kid can get their parent's finger on the fingerprint scanner, sure. The authentication part of the process is moved to the device's security system, so that's fingerprints, passcodes, and facial recognition.

.. but biometrics can be lost too. I could lose my finger, I could have a facial injury. The algorithm could be changed and suddenly I can't log into anything anymore. Or I simply age and my faceId stops working some day. I don't know but biometrics only sound smart initially but it seems very brittle if you think about it. Plus there are plenty of stories of people who were able to unlock somebody else's phone rando…

* On Apple devices TouchID allows you to register multiple fingers. And if you have a severe facial injury it will fall back to a password if it can't identity you.

* No one is unlocking their friends phone via FaceID unless they are unconscious and they have deliberately disabled the awake-detection feature.

* It is not theatre for nothing. It is a far more secure and convenient form for authentication.

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

#389

Post by dane-pgp »

md_ wrote: post #266
dane-pgp wrote: post #255

Earlier quoted context omitted.

The point being, the FIDO Alliance reserves the right to blacklist any device that an attacker manages to extract the secret keys from, which has the consequence that 99,999 other people have their devices bricked. Also, the Alliance could decide to blacklist a manufacturer just because they haven't implemented some new policy (like requiring a DNA scan of the user) so you better make sure that you buy a device from…

> The point being, the FIDO Alliance reserves the right to blacklist any device that an attacker manages to extract the secret keys from, which has the consequence that 99,999 other people have their devices bricked. 1. By what mechanism can they blacklist a device? A given relying party can choose to use or not use attestation and, if they choose to use it, which certificates to trust. But that's between you and the…

> A given relying party can choose to use or not use attestation and, if they choose to use it, which certificates to trust.

True, and a website could decide to issue its own certificates rather than get one from a CA trusted by browsers, but in practice (and potentially one day by law) most sites will defer to the FIDO Alliance to determine which devices are "sufficiently secure".

> the FIDO Alliance--which is just a standards body and does not (AFAIK) even publish anything like a CRL for "bad" attestation keys

"The FIDO Alliance Metadata Service (MDS) is a centralized repository of the Metadata Statement that is used by the relying parties to validate authenticator attestation and prove the genuineness of the device model."[0]

> That's crazy; can you point out where anyone other than you has ever proposed this?

"If the private ECDAA attestation key sk of an authenticator has been leaked, it can be revoked by adding its value to a RogueList."[1]

> DNA scan? What are you talking about?

I picked a deliberately extreme example to make the point that there are requirements for these devices that users might not be happy with (but might not have any choice about, once the capability becomes ubiquitous). That specific example may never come to pass, but I don't think we should assume that allowing RPs to put arbitrary conditions on the hardware we use is a power that won't be abused.

For added context: "FIDO will soon be launching a biometric certification program that ensures biometrics correctly verify users. Both certifications show up as metadata about the authenticator, providing more information to enable services to establish stronger trust in the authenticators.)"[2]

> This assertion you are making, while bizarre and wrong ... a bad-faith argument.

Maybe you should have assumed good faith.

[0] https://fidoalliance.org/metadata/

[1] https://fidoalliance.org/specs/fido-uaf-v1.2-rd-20171128/fid...

[2] https://fidoalliance.org/fido-technotes-the-truth-about-atte...

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

#390

Post by Spivak »

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.

Something you is a an authentication factor that doesn’t need to be secret to be secure. That’s the whole point. You can have a high-res 3d model of my finger but you can’t create a human with my fingerprint.

In the same way that the security of something you know is a scale based on “how difficult is your password to guess” or “how hard is it to crack the hash” the security of something you are is a scale based on “how difficult is it for someone to create a fake that tricks this specific machine into thinking it’s reading metrics from a live human.”

The security lives in the system reading the metrics not your body which is why you don’t have to rotate your face every 90 days.

A cheap fingerprint reader is the 4 digit pin of something you are. Retina scans that take temperature, look for blood flow and eye movement are the correct horse battery staple.

Post reply on HN