Keeping your password in memory like that is pretty sketchy IMO. Then again, that's exactly what the fingerprint reader on my Lenovo tries to do if you set it up (though it uses a token and not the full password).
The reason TPMs are used is the unfortunate reality that most passwords are absolute shit. Very few of them are longer than 12 characters and even fewer don't have numbers and special characters at easily guessable positions. A TPM generates an actually secure key, and the brute force protections inside of it will make sure even quite insecure passwords don't get brute forced easily.
Another problem with this approach is that your password can be reset, remotely if it's attached to a domain. You can turn off a laptop, alter the domain password, boot it, and log in with the new one, even if you've forgotten the old password. With your proposed solution, you'd be disconnecting the password from the encryption password.
At that point, you might as well set the password to be the same as your login password and enable automatic login. You'll need to update both when they change anyway.
This TPM+PIN solution is actually the easiest, most common mitigation recommended for all of Bitlocker exploits I've seen.
> Very few of them are longer than 12 characters and even fewer don't have numbers and special characters at easily guessable positions
Why yes because adding a $%^* at any point in your password easily increased the entropy and didn't make it significantly harder to remember...
Realistically randomly generate your password and if you are the forgetful type write the bloody thing down. In 2025 you should be inputting it at most once every now and then and for disc encryption effectively never...
A long password in a locked drawer or safe is much more secure than Summer2025!5
It doesn’t have to literally be your password. It could be some one-time proof that the user entered the correct password.
This isn’t a replacement for a TPM, it’s a way to use a TPM in a sensible manner. You have the TPM do the password -> key derivation, which lets you prevent brute force attacks (at least without a TPM vulnerability or physical chip-level attack). I imagine the TPM could also be used to securely tell the OS who did the initial login so it doesn’t have to prompt a second time.
Having a separate PIN means something else to forget and people will tend to choose the easiest option. We’ve barely managed to convince people to put up with having a password at all. If it’s a choice between password or password+PIN, people are going to pick the former. That option should be secure, and it’s not that hard to design a system where it’s more secure than having a separate short PIN.
Sorry to be unclear. Read that as “it doesn’t have to be your password.” As in, the fact that you’ve entered the correct password can be communicated to the OS without actually sending it your password. You can do it more securely than just setting a flag if that’s a concern, although the fact that the disk is readable at all is solid proof that some user’s password was entered correctly, so you don’t have to defend against too much.
> As in, the fact that you’ve entered the correct password can be communicated to the OS without actually sending it your password
Can't communicate with the OS -- the disk is locked.
> You can do it more securely than just setting a flag if that’s a concern
Now we just wait for a vulnerability in this mini-app stored in unencrypted storage to be able to set some flag and wallah, we bypass the user's password at the OS level.
Of course you can communicate with the OS. The disk is unlocked at this point, not that you’d want to use persistent storage for this. You’d put the info in RAM.
Doing this in a secure fashion doesn’t seem very hard. For example, hash the password in the same way the OS does. Hash that hash with some salt. Put it in memory at some agreed location. The OS can retrieve it, verify the hash and proceed if it matches. And of course erase the message.
If you’re worried about replay attacks from someone who can capture the message between login and the OS verifying it, you can add the current time to the hash. If you don’t trust the clock, I’m sure the TPM can produce an ephemeral nonce for both sides to use, or the OS could store a hash of each message after verifying it, and reject any reused message.
You’ll never be safe from software vulnerabilities, but this reliably prevents an attacker from reading your disk from a cold boot without knowing or cracking your password.
How? With my proposal, if an attacker can obtain your password then they can get in, otherwise they can’t. With TPM + PIN it’s the same, just with your PIN instead.
> Keeping your password in memory like that is pretty sketchy IMO.
Every Windows version since "... for Workgroups" keeps the passwords of every logged-in user in memory as plaintext. This fact is widely exploited for privilege escalation and lateral movement in Windows environments.
Which is why recently Microsoft has been pushing very hard to replace the account login password with a TPM managed PIN. This way the (Microsoft) account password is rarely needed and never stored in memory.
Do I understand it correctly that LSA Protection leverages VBS/VSM such that the "actual" Windows instance is punted into a VM while LSASS and friends run in a separate VM, with communication between the two controlled by a specialized version of Hyper-V?
The reason TPMs are used is the unfortunate reality that most passwords are absolute shit. Very few of them are longer than 12 characters and even fewer don't have numbers and special characters at easily guessable positions. A TPM generates an actually secure key, and the brute force protections inside of it will make sure even quite insecure passwords don't get brute forced easily.
Another problem with this approach is that your password can be reset, remotely if it's attached to a domain. You can turn off a laptop, alter the domain password, boot it, and log in with the new one, even if you've forgotten the old password. With your proposed solution, you'd be disconnecting the password from the encryption password.
At that point, you might as well set the password to be the same as your login password and enable automatic login. You'll need to update both when they change anyway.
This TPM+PIN solution is actually the easiest, most common mitigation recommended for all of Bitlocker exploits I've seen.