Hacker News Reader

Comment by elevation | Hacker News Reader

How could this information be surfaced in a reasonable way in administration software?

Say I have a remote employee who is only able to access your internal systems via his yubikey. His fingerprint is "Genuine Antelope".

Next week, he accidentally damages his yubikey. He has another one in the drawer, but I need to authorized him. I create a new session for him on the provisioning portal (so he can enroll the new key) but now his fingerprint is "Interesting Elephant". What do I do with this information?

It might be better to log the exact forensics and show the administrator the differences, e.g, "User has a new font called "my_handwriting.ttf" since a week ago", or "appears to be a totally different processor, and the new system has Russian fonts installed".

View on HN

> Next week, he accidentally damages his yubikey. He has another one in the drawer, but I need to authorized him

They should be authorized ahead of time.

> What do I do with this information?

Not much. You can't authenticate a person using their (public) fingerprint information.

Your problem boils down to: "How can I verify someone's identity over the internet". You can exchange emergency recovery codes ahead of time (e.g. in an envelope), you could trust public keys from both of their yubikeys, but they can be stolen.

> You can't authenticate a person using their (public) fingerprint information.

Yes, but it's a signal! There's a cost to spoof it. A scammer could cheaply start a VM that clones your font profile, but at what cost could they replicate your CPU SKU and GPU combination to provide identical webGL timings?

Other signals include the ability of your employee to show their face on a video call, to sound like themselves on a voice call, the ability contact you from their home IP, to receive official mail at their listed address, to produce a second 2FA token you'd previously registered (but not activated) or repeat a code word you'd exchanged. Any of these things can be spoofed, bypassed, copied, or burgled, but each one imposes some cost on the attacker.

The question is how to surface this information in a way that equips help desk staff and doesn't deceive them into authorizing unnecessary risks.

> A scammer could cheaply start a VM that clones your font profile but at what cost could they replicate your CPU SKU and GPU combination to provide identical webGL timings?

At the cost of getting the target to visit a website where they silently harvest those details - close to 0. You don't need a VM and an entire rube goldberg machine to spoof anything, you only need to craft the "employee registration" HTTP request to include your spoofed values.

Especially now with LLMs and agents, they would set everything up for you in a matter of minutes, maybe an hour.

Personally I would avoid this whole conundrum by issuing at least 2 security keys. If both get lost or damaged simultaneously then they're either replaced in person, or you can fall back on pre-shared recovery keys which are strictly kept offline + password which is strictly kept in memory + video call, depending on your needs.

Additional factors like the ones you talk about could still be useful for defense in depth but they should never be relied upon for authentication itself.

Reply on news.ycombinator.com