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

481–490 of 525 posts

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

#481

Post by dane-pgp »

md_ wrote: post #475
dane-pgp wrote: post #389

Earlier quoted context omitted.

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

> True, and a website could decide to issue its own certificates rather than get one from a CA trusted by browsers… That’s quite different. In your example, if a website does so unilaterally, client user agents break. In the FIDO case, nobody else knows or cares which authenticators an RP trusts. More broadly, I don’t get this conspiracy theory. You’re worried…the FIDO alliance will abuse their very limited power to……

> But “my employees must use a fips-certified key” (or “my customers must use a hardware key”) is reasonable and ultimately non-negotiable if you want people to use your protocol.

I think this is the crux of where our disagreement lies. I grudgingly accept that FIDO makes it easier for companies to check that their employees are storing their keys on company-approved devices, but I don't think that arbitrary websites should be given the power to make demands about the hardware that visitors must use to create accounts. That seems like a worse position for user freedom than we have today with passwords.

You might say that websites already have this power, in some convoluted way. They could say "Enter your credit card details and postal address here and we'll send you a custom device you can use to log in to our website", but in practice no company does that. (Banks and governments are maybe special cases, and less concerning given that: their authenticators are managed out of band; they are highly regulated; they usually have actual branches that you can go to in person to sort things out; and people generally choose to interact with banks/governments that are based in their own country).

Attestation changes the market dynamics here. Suddenly it becomes acceptable for sites to bully users into buying certain types of devices, and for governments to start demanding that these devices be used as online IDs (at least for age verification, to start with). Even if companies don't abuse this power to keep people in their ecosystem (e.g. Apple sites giving you special features if you log in with an Apple device), the first casualties are going to be open source hardware and software implementations, which will be deemed insecure, and further normalise the idea that users can't go online without running proprietary code.

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

#482

Post by dwaite »

blep_ wrote: post #435
dwaite wrote: post #348

Earlier quoted context omitted.

The vendors here are proposing a platform synchronization method such that these are both backed up as well as shared across devices within a particular platform account. There likely is a hardware key that supports export and import of keys (even if that winds up being a fork of say the Solo key firmware). However, as an end-user one doesn't want to accidentally forget to export keys for a while, nor do they want to…

FIDO, at least, doesn't store per-site keys on the device. You only have to back up and restore the master key, which doesn't change and so doesn't need to be scheduled.

When generating non-resident/non-discoverable credentials, many authenticators will use a source of randomness, an internal secret and possibly the name of the requesting origin to generate a private key, and export either a seed value or a wrapped version of that key in a 'credential handle' during registration. You have to pass that handle back to authenticate someone, which the authenticator will process and check to see if they were the one that issued it. Such credentials are only usable for secondary factors, because you need to know what list of registered handles to pass to the authenticator, which means you will typically need to know who the requesting party is.

Web Authentication and CTAP 2.x added the notion of discoverable credentials, which do not require such handles and as such are usable as a primary factor for authentication. A site can simply ask into the void "do you have any credentials for example.com" and potentially get back an answer. These necessarily require state.

Several of the platforms do not want to deal with the security ramifications of exporting wrapped keys, and simply generate and store keys even in the traditional U2F case. This is actually why the terminology was changed from 'resident' to 'discoverable' in WebAuthn L2 and CTAP 2.1 - a non-discoverable credential has the old behavior where you have to supply the handle to get back a response, but there's no guarantee that credential won't be resident in some state store of the authenticator.

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

#483

Post by raxxorraxor »

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 want to have both, a hardware key and a password. A password alone always has to grant me access again, ideally without needing to register a machine too. Honestly I hate that this is so widespread already, I want my devices to be a non-recognizable ghosts for security purposes. An access log would be more appreciated.

I have a Yubikey and use it as a part of my passwords. But I would like to have a second master password that I only use in emergencies. Yes, it is easy to forget so make sure you don't. But a password that is rarely used is also rarely exposed to third parties.

To be honest, the most problems I see with FIDO is the lacking trust in the alliance of companies behind it but I don't know too much about the technicalities of FIDO.

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

#484

Post by WhyNotHugo »

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.

You can have a backup key and keep it off-site (e.g.: at a family member's place).

If you lose your main key, you can resort to that one to re-gain access.

Keys that allow backing up the secret material are tricky, since they could potentially be cloned and someone would have a backdoor with you being unable to know of it.

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

#485

Post by tialaramex »

rdl wrote: post #442
tialaramex wrote: post #384

Earlier quoted context omitted.

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

It might be that if someone has a hardware key which makes a sufficient attestation, you disable some OTHER supplemental authentication mechanism; like, if it says it requires a biometric, then you could allow auto-login in a context where you'd otherwise also require a pin or other second factor.

You can't say "Does it require a biometric?". The attestation is proof this device was issued by this manufacturer, so you're going to be whitelisting manufacturers and maybe specific product lines. Somebody technical needs to understand how to determine matches, and then somebody with authority needs to decide which ones are acceptable (maybe they're going to buy and test each model?), only if you're actively doing this is it even viable.

Now, I want you to imagine if corporate has to approve motor vehicles for the HQ's 600 vehicle car park. Of course the CEO's BMW M5 daily driver is approved, and for the first week maybe the random cars owned by people who regularly use that car park get whitelisted pretty easily. By the next month though, one of two things, either you're told just buy the same exact model of car as the CEO to "save trouble" or everybody just tells you to use a different car park nearby, and the HQ real carpark sits mostly empty because approval is a hassle.

The right answer, you can see, is to just not have a rule whitelisting cars at all. It's a bad rule.

If all you want to ask for is "Use a second factor" then you can do that, there's a flag in WebAuthn, and the resulting signatures have the UV bit flag set (all WebAuthn signatures have UP set, but Presence of users is distinct from Verification of users). Because it's a signed flag, even though it's a single bit, you can rely upon it unless you don't trust the device you enrolled. But, again, why? What is your threat model where your users do deliberately enrol untrustworthy devices but presumably never just helpfully enrol a device for a crook ?

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

#486

Post by hansel_der »

CyberRage wrote: post #64
hansel_der wrote: post #57

Earlier quoted context omitted.

> Oh gosh... your raw bio-metrics are never stored anywhere... right, who would do that... i mean for what purpose...

I mean you don't have to give it away if you think Google is storing databases of fingerprints for the lizard masters to track you down. FIDO simply wants to make authentication stronger, you can use hardware keys that have a key burnt into them which is unique and much harder to brute-force than passwords. Again according to how biometrics are described in whitepapers\industry, we extract features from the fingerpri…

> I mean you don't have to give it away if you think Google is storing databases of fingerprints for the lizard masters to track you down.

also you

> We leave biometric traces everywhere, all the time. do you cover your face and wear gloves in public? hmmmm...

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

#487

Post by mmis1000 »

lxgr wrote: post #341
mmis1000 wrote: post #328

Earlier quoted context omitted.

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.

It's much more than a non-rememberable password: One of the most important attributes of WebAuthN/FIDO is that it's fundamentally impossible to fall victim to phishing. Assuming your browser isn't itself compromised, it is impossible to authenticate using a key for service.com on evil.com. Passwords can't do that. (PAKEs or other challenge/response protocols theoretically could, if implemented in the browser and not…

However it will be weaker to malware compares to the original one. Because if you can export or sync the key, then malware probably also can if your device is compromised.

The guarantee that key is never cloned unknowingly even machine fully compromised isn't in this new model.

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

#489

Post by raxxorraxor »

lxgr wrote: post #331
zozbot234 wrote: post #188

Earlier quoted context omitted.

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] ht…

This is such a restrictive security model though. Sure, devices are already identifiable. That is a security issue in my opinion. Yes, authentication is one use case where it is actually beneficial. But the security threats from this are far greater in my opinion even if you include phishing. Privacy is a concern for users even if it is conveniently ignored here.

> Your privacy is important to us.

Privacy statement of the group and I think it is a straight lie. This is a major if not the major security concern. TPM didn't address the problem and therefore isn't a too popular guest.

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

#490

Post by raxxorraxor »

lxgr wrote: post #462
zozbot234 wrote: post #439

Earlier quoted context omitted.

> In a compliant implementation, you can add a new external authenticator from an existing trusted device, and a new trusted device from an existing external authenticator. You can kinda sorta do this with WebAuthn if the service you're enrolling into allows for multiple authenticators (the spec recommends this, but some services don't allow more than one). But then you have to repeat that enrollment step with all de…

To securely store device-specific authentication credentials such as WebAuthN those used by WebAuthN/FIDO, for example. > The only uses I can think for it are nefarious, i.e. allowing outside services to track the user and violate their privacy. A smartcard would be one of the worst or at least most complicated ways to implement tracking: It can communicate with the rest of the system only through an extremely limite…

But if I never adopt TPM these compromises aren't necessary. Doing so would only give me negatives.
Post reply on HN