But most people don't want to enter a password, and if you make people enter a password too much, they'll choose terrible passwords and put them on a sticky note. Windows Hello can only be done securely with a TPM. A server that I want to turn back on all by itself after a power outage can only be done securely with a TPM.

I want a TPM in my computer so I can have the security and convenience. Yes, it's another point of failure. But I need backups in case the hard drive fails anyway. And besides, the OS can be designed so I can enter a password if I need to use the drive without the TPM.

>Windows Hello can only be done securely with a TPM

I think in general biometrics are in the same ballpark as low-entropy passwords. IDK, I personally have no faith in trusted computing hardware because it can be broken with the right equipment. You're right that it can be used alongside ordinary security measures, but I just think it encourages putting your eggs into a cryptographicially-weak hardware-strong basket (which represents a downgrade because crypto is stronger than hw).

>A server that I want to turn back on all by itself after a power outage can only be done securely with a TPM.

Can you describe how this prevents a MITM attack? I assume you mean a remote server? I've heard of colocation setups like this, but I think they rely on a couple of unstated assumptions.

> >A server that I want to turn back on all by itself after a power outage can only be done securely with a TPM.

> Can you describe how this prevents a MITM attack? I assume you mean a remote server? I've heard of colocation setups like this, but I think they rely on a couple of unstated assumptions.

I'm not sure what you mean by prevent a MitM attack, unless you're worried about someone with probes MitM-ing your TPM-CPU connection in the DC.

You can bind a TPM to measurements on the host (let's say for argument's sake you want Secure Boot state, Option ROM state, and UEFI state), then configure the OS to ask the TPM for the (or rather, a) decryption key during boot.

The TPM will check that the state(s) you bound to is (are) the same as when you bound them, and if so it will give the OS the key. Your disk is encrypted, but the boot process is automatic/unattended, as well as completely contained within the server chassis.

There are ways to attack this hypothetical setup, buuuuut there are ways to attack remotely entering your disk password as well, and bear in mind that denial of service is a security vulnerability. Tradeoffs.

I agree that biometrics are in the same ballpark as low-entropy passwords, which means their security relies on avoiding offline attacks. My ATM card is protected by a 4-digit pin. That's perfectly secure, because the ATM network won't let you enter a wrong pin more than a single-digit number of times before locking the account.

Windows Hello allows you to log in with a 6-digit pin. That's perfectly secure, because the TPM lets them design a system where you can't do an offline attack on the pin. Too many wrong entries and you'll need to use your password.

I doubt there's more than two dozen bits of entropy provided by finger print readers or facial recognition authentication, but you can make an acceptably secure login experience with it because, again, the TPM lets you prevent offline attacks.