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

311–320 of 525 posts

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

#311

Post by Mindless2112 »

Animats wrote: post #194

Does this imply that every service you connect to knows your unique identity?

No, each registration generates a new key pair; but maybe:

> The signature counter is a strictly monotonic counter and the intent is that a relying party can record the values and so notice if a private key has been duplicated, as the strictly-monotonic property will eventually be violated if multiple, independent copies of the key are used.

> There are numerous problems with this, however. Firstly, recall that CTAP1 tokens have very little state in order to keep costs down. Because of that, all tokens that I’m aware of have a single, global counter shared by all keys created by the device. [...] This means that the value and growth rate of the counter is a trackable signal that’s transmitted to all sites that the token is used to login with.

http://www.imperialviolet.org/2018/03/27/webauthn.html

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

#312

Post by lxgr »

_vdpp wrote: post #280
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 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 keys protected in the HSM, but at least it does not automatically expose it to software.

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

#313

Post by sdfgdfgbsdfg »

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.

receiving synced key material in RAM significantly alters the threat model. Apple's current passkey implementation does not, at any point, handle unwrapped key material in the operating system. I expect all other implementations to follow.

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

#314

Post by j_san »

bedast wrote: post #290
cmeacham98 wrote: post #262

Earlier quoted context omitted.

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.

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)

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

#315

Post by danans »

jeroenhd wrote: post #267
criddell wrote: post #227

Earlier quoted context omitted.

Why do you trust your laptop scanner? Have you let other people try to unlock with their fingerprint? FWIW, my daughter's laptop is a Dell.

I've tried unlocking my laptop's scanner with my other hand and I've asked other people to put their finger on it to see if it does some kind of weird matching based on finger type. No problems so far. It even works across both Windows and Linux if I use the right Windows reboot incantations. Since there is nothing genetic about fingerprints, I'd personally consider your daughter's laptop to be defective if you're ab…

> Since there is nothing genetic about fingerprints

While it's true that even identical twins don't have the same fingerprints [1], it's not true that there are no genetic factors in the general shape of fingerprints [2]. I agree that it's unacceptable if a fingerprint reader isn't good enough to distinguish identical twins based on the differences in fingerprints though, as those should be the most similar fingerprints possible, essentially setting a floor on the minimum uniqueness in the problem.

It seems like they would use identical twin derived validation data sets to ensure this.

1. https://www.nytimes.com/2004/11/02/health/the-claim-identica...

2. https://www.mcgill.ca/oss/article/did-you-know/you-inherit-p...

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

#316

Post by aaaaaaaaata »

md_ wrote: post #212
lizardactivist wrote: post #168

FIDO also enables great opportunities for tracking. But we're not supposed to talk about that.

Hmm, what opportunities? Genuinely curious what you mean here.

If you use the same public keypair across many unrelated sites, an observer could blah blah blah

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

#317

Post by lxgr »

tadfisher wrote: post #233
rdl wrote: post #226

Earlier quoted context omitted.

Ideally there would be a way to create "tickets" or something from an authenticator in advance and then use them for registration without physical access to the device. Then I could have 100 tickets from my backup on my master, keep the physical backup in a secure offsite location, and enroll new services using master + backup-tickets. When I run out of tickets, generate 100 more. Being able to export/back up/restore…

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 fingerprint verification" – all assuming you do trust the manufacturer.

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

#318

Post by blibble »

aaaaaaaaata wrote: post #294
droopyEyelids wrote: post #257

Earlier quoted context omitted.

I don't think any AWS account allows more than one!

This has been talked about in HN comments almost daily for like a week — does anyone from AWS/Amazon read this forum, or are they too busy performing blood sacrifices trying to recruit graduates?

more like 2 years

they do know about it (I had a friend who was a PM there), but it's low priority...

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

#319

Post by lxgr »

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.

How would you add a new key at a later point in time (i.e. after your initial registration of e.g. a main and a backup key, after having lost the main key and wanting to add a new backup/main key)?

The FIDO/WebAuthN model does by design not include a stateful/centralized authority that could maintain the required state for any such solution.

Post reply on HN