back

by rdl·4y ago·view on hn ↗
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.
1 comments
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 ?