151–160 of 247 posts
on the subject of encryption keys and memory there is something you can do: - if your CPU supports it, enable memory encryption. - if your TPM module supports this look for MemoryOverwriteRequestControl & MemoryOverwriteRequestControlLock (/sys/firmware/efi/efivars/) and toggle them. make sure that your computer always reboots and never powers off. memory will always be wiped on boot.
Earlier quoted context omitted.
If you’re at all serious about security and not user convenience, you deploy BitLocker with a PIN instead of TPM only. And then a whole class of vulnerabilities goes away.
Just a PIN? For most people that's a 4-digit number, which has a worst-case scenario of 10,000 attempts and a median of only a few hundred. Why not use a full 8-digit password?
https://learn.microsoft.com/en-us/windows/security/hardware-...
> For example, when BitLocker is used with a TPM + PIN configuration, the number of PIN guesses is limited over time. A TPM 2.0 in this example could be configured to allow only 32 PIN guesses immediately, and then only one more guess every two hours. This totals a maximum of about 4,415 guesses per year. If the PIN is four digits, all 9999 possible PIN combinations could be attempted in a little over two years.
Earlier quoted context omitted.
Anyone with physical access. I think it is understandable from the phrase. There is a common misconception about how lock-screens in general work - they usually just prevents using the current hardware and software as it is to access the current OS. But the disk encryption is the main thing that prevents modification and other kind of access to actual data. And if the disk encryption key is lying in the memory, then…
Anyone with physical access, significant tools, and experience. The FBI has people who can pull data out of memory after freezing the RAM but the average laptop thief doesn’t so how serious this is depends significantly on your threat model. If you’re not a major criminal, bitcoin whale, or intelligence target this is almost certainly academic.
PS: Downvoting is not a rebuttal. Disk encryption is not effective security on a suspended (sleeping) system. That is a fact.
Earlier quoted context omitted.
Veracrypt is more difficult to set up - whether on one machine or a fleet. Bitlocker is a few buttons in the UI, configurable via Group Policy, and so much more. What is brittle or awkward?
"PLEASE ENTER YOUR BITLOCKER RECOVERY KEY" Where is it? A) Uploaded to microsoft B) Somewhere in EntraID? C) Somewhere in our onprem AD? D) Written down on a scrap of paper when I set up the laptop the fact that they never ask for the passphrase is a weakness of the system. Because now you have an extremely difficult situation as soon as you're off the happy path. It's also like 64 characters alphanumeric with no cap…
In fleets users wouldn't even be setting up their own code.
I've installed Windows thousands of times on dozens, probably hundreds of systems - long ago I even worked on the Windows team and was installing it every day - and in the last 20 years (yes, I ran Vista Ultimate in 2006) I've had to deal with Bitlocker recovery prompts perhaps 20 times - not 20 times per machine, 20 times across all of them.
But if you do this, don't you have to enter two passwords each time you wake? One for LUKS, one for the system login?
Well yes and I don't see how this can be avoided.
If you're the only one with the disk password then the simple answer is make both passwords the same and make the different parts of the system communicate better.
If you want multiple users, give them each a different boot password and encrypt a separate copy of the disk key with each one. That password can be their login password too, or it can encrypt their login.
I don't think this bothers me. The only reason that I do the disk encryption is so that I don't have to worry about people going through my laptop to steal tax documents and/or credit card stuff when I sell the laptop. I of course also wipe the laptop too, but I figure that if the data is encrypted at the drive level then there's very little risk of anyone being able to use some kind of forensics tool and recover dat…
Assuming the encryption key is strong, the wiping is theoretically redundant.
Earlier quoted context omitted.
It absolutely is and they have most the enterprise market.
Okay, yes, sure. It definitely is the most-used encryption software for Windows. But I would never trust it a second, being proprietary and known for issues. You likely know that, but for the benefit of others: 38C3 - Windows BitLocker: Screwed without a Screwdriver https://media.ccc.de/v/38c3-windows-bitlocker-screwed-withou... https://www.youtube.com/watch?v=5eNtT2p12cM
Bitlocker + PIN is as secure as anything.
A vulnerability can’t leak your key if the TPM doesn’t know the entire key and relies on the user to supply the missing parts of the key in the form of a PIN.
Earlier quoted context omitted.
If you’re at all serious about security and not user convenience, you deploy BitLocker with a PIN instead of TPM only. And then a whole class of vulnerabilities goes away.
If you are at all serious about security you don't consider Windows. Depending on how serious you are you also don't consider MacOS. And then you kinda have a couple of things to chose from but ultimately you need to build your own security depending on your attack/threat model
Back in the late 1980s it was clear that it would be no problem at all to hook up a hard drive to a digital phone exchange and record all the calls! I had a strict policy of "don't talk about anything illegal using electronic communication" even when it was rather banal stuff like selling weed.
The carelessness of people at Facebook documenting policies that nobody in their right mind would document boggles my mind: you might as well leave it mysterious why you didn't crack down on scam ads, for instance. When I've been involved in minor conspiracies, say when we had an HR problem with another employee, I've always made the point to meet furtively in person and avoid leaving a paper trail so that I'd never need to explain an email I wrote in front of an unfriendly audience.