Hacker News new | past | comments | ask | show | jobs | submit login

> I am not sure how comfortable I am with passwordless login unless the keys are kept purely in hardware such as a TPM.

Shouldn't this be something for the user to decide? Using a TPM as a key is a bit silly; it amounts to turning the computer as a whole (strictly speaking, its motherboard and/or CPU) into a big smartcard/FIDO key. If that physical device breaks down, the associated identity is toast. A purely software-based key you can always back up.




Yes that's fair, it's a trade-off. Thinking more, there are really three levels of protection I see.

1. Keep keys in a file/the keyring. This protects them somewhat from non-root users on the same machine. It also provides phishing protection, which is really the most important aspect of U2F/WebAuthn to most people. If your computer is compromised, all the keys are compromised.

2. Keep keys in the TPM. The only additional protection over #1 is if you recover your computer after it is compromised, you can be reasonably certain the attacker could not make a copy of the keys and thus can no longer use them to authenticate. Arguably this is not a particularly useful protection.

3. Keep keys in the TPM/secure enclave and unlock them via biometric. This does provide meaningful extra protection if every use requires an unlock. Then if your computer is compromised, the attacker will have to either defeat the biometric unlock, or trick you into unlocking for every authentication attempt.

#1 is what I do right now for rust-u2f, and I think you're right #2 is not really useful. So maybe it's worth just implementing FIDO2 without worrying about TPM support. What I really was talking about was doing #3 for Linux, but I don't see a way to meaningfully accomplish it without tight hardware integration.

P.S. It is recommend to register multiple FIDO keys and/or have backup codes for accounts as a way to mitigate the issue of one physical device breaking toasting an identity. Not all providers may support this, for silly reasons.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: