Hacker News Reader

Comment by nacs | Hacker News Reader

Reminder that by using Bitlocker, you're using a closed source encryption for which Microsoft will happily hand out your recovery key on request.

https://www.forbes.com/sites/thomasbrewster/2026/01/22/micro...

View on HN

Tangentially: Microsoft telemetry collects the serial# of your devices and reports it (with your IP and MS account) back to the mothership, and some printers embed their serial# in printed pages.

So take countermeasures if you print something out criticizing any groups that abuse political or law-enforcement powers.

Only if you store your key with Microsoft, which is not required or the default if you're using a local account which I assume most privacy sensitive people are.

Not to mention that unless the bitlocker activation flow changed recently, it specifically asks you how to store your backup keys, with a choice given been local options (eg. usb drive, printing it off, etc.) and saving it to your microsoft account.

dell opts you in without telling you. one day you'll just reboot to an unexpected bitlocker screen and have to figure out whether you're getting ransomwared before eventually digging a key out of your microsoft account you weren't aware was there.

Agreed it's optional (I've seen and used that option), but are local accounts even a thing any more? Or are you just referring to "not MDM controlled" accounts?

  > are local accounts even a thing any more?

Yes, most certainly. You can easily convert to a local account in Settings, and there is still a workaround to avoid using a Microsoft account during install. Or the far more stable and reliable method of using Rufus to create the installer ISO which has an option to use a local account without the hassle.

Rufus for install + Win11Debloat post-install is a nearly effortless way to get an ad-free, local only Win 11 install that persists through updates which removes pretty much all notorious Win 11 pain points (plus additional customization if desired).

I've been doing it for years and so reading Windows 11 complaints on HN always feels like they're coming from a strange parallel universe since I never have to deal with any of it.

"modify the windows installer via a binary patch to work around the continued bloat and feature crippling" really isn't "local accounts are supported" in my book. that's like saying "the 1965 ford mustang was an electric car" because someone did a conversion on it a few years ago.

and the actually supported workarounds have disappeared, last I saw - bypassnro and disabling internet both failed completely for me, the last time I tried. maybe they have come back (it has intermittently failed in the past and come back), but they're very clearly doing more to remove it than they did a year+ ago when bypassnro worked easily and consistently.

> if you're using a local account

Unfortunately Microsoft keeps working to destroy that option and force consumers to make a remote account. [0][1] Their consistent moves towards wanting to co-own my computer were one of the many last-straws that made me migrate everything to Linux this year.

> Local-only commands removal: We are removing known mechanisms for creating a local account in the Windows Setup experience (OOBE). While these mechanisms were often used to bypass Microsoft account setup, they also inadvertently skip critical setup screens, potentially causing users to exit OOBE with a device that is not fully configured for use. Users will need to complete OOBE with internet and a Microsoft account, to ensure device is setup correctly.

[0] https://blogs.windows.com/windows-insider/2025/10/06/announc...

[1] https://www.windowslatest.com/2025/10/07/microsoft-confirms-...

Like it's easy to create local accounts on windows 11… the default are microsoft accounts and microsoft having access to your key.

Also this: https://www.techspot.com/news/112410-security-researcher-mic...

Bitlocker can use keys that are local only, but the default for home editions of Windows was to use the online account to back it up.

'Happily' is also a stretch, as they really don't have a choice if served a valid court order.

If you want encryption that is safe from the US government, keys need to be stored in your head. Anything physical is subject to court orders.

Does that mean it's not the de facto standard on Windows?

So exactly like FileVault?

for enterprises, where this doesn't really matter, bitlocker is great.

if by "great" you really mean "fine".

It's still brittle, awkward and puzzlingly awful UX despite being the literal standard for the platform.

Compare it to any of the actively maintained alternatives, Filevault for MacOS (which is wonderful and never sends your key to be kept somewhere else) or LUKS on Linux.. heck, even Veracrypt is actually easier to understand and more robust.

>if by "great" you really mean "fine".

no, i mean great.

managing a fleet of 100+ laptops with bitlocker is a breeze. its so seemless that the users don't even realize its enabled (i.e. no UX issues, at all).

on the other hand, i am not managing 100+ laptops that use veracrypt. sounds absolutely awful. i've never managed an apple fleet, so i can't speak to that, and will take your word on it.

for personal use, i do not recommend bitlocker (or windows, really), but for already-windows enterprises? absolutely

Managing an Apple fleet is similarly fine, and that includes using any of the MDM tooling that also does key escrow on enterprise Filevault devices.

Flicking a button to turn something on is not what I'm talking about, that's normally the easy part of any setup, and I judge people harshly who only take that aspect of something into consideration when discussing systems.

Brittle is what happens when you haven't logged on to the machine in 60 days, trust with AD is broken, TPM has a glitch and wipes the in device key and forces you into recovery... or god forbid you service the laptop and now you have to enter recovery mode.

Then you're in a nightmare, trying to give someone a super long passphrase over the phone is a not-too-uncommon occurance.

That's assuming you have a good policy for storing the recovery keys. Too loose and they're handed out to everyone, sort of defeating the purpose: too strict and you need the IT department (or specific members), and its still predicated on the notion that you have a policy for it... Given that Admins are a dying breed... I don't think this is workable.

If you compare with Filevault on MacOS: which tracks the credentials of the logged in user; there's no "issue" if the device loses trust because ultimately you always use the real unlock key: not something cached in a "secure storage".

maybe i am missing something, but how did veracrypt solve all of the admin and policy issues you’re bringing up? (specifically for large enterprise fleets)

If you use your key every day you tend not to forget it.

If I as an admin give you your key: it is “leaked” effectively.

>If you use your key every day you tend not to forget it.

hoping users don’t forget their password is a very weak policy.

specifically, the policy and admin points you brought up above, how does veracrypt solve them?

You don't have remote back ups enabled?

veracrypt does not include a remote backup system

Of the work, not of the encryption.

we're talking about veracrypt vs. bitlocker in a managed enterprise environment.

whether there are backups or whatever else is irrelevant because it would be true in both the veracrypt and the bitlocker scenario.

We are talking about IT policies. I don't know what YOU think we're talking about.

We're sort of talking about two things and conflating them.

I'm sort of talking about my user experience of the system, and I'm getting it in the neck from helpdesk.

Enterprise rollouts are different from anything I actually deliver, despite pushing out thousands of windows servers: I have complete control over those.

Same as my local PC.

But as a user on a PC I'd buy from a store, I'm not going to forget my password without expecting to lose access to my system.

>We're sort of talking about two things and conflating them. [...] But as a user on a PC I'd buy from a store

i said multiple times that i was talking about a managed fleet in an enterprise environment, and even specifically said that i dont typically recommend bitlocker for personal use, so i am not really sure what to say here. i was really clear.

Yes, but I still think we've been talking passed each other.

I doubled down on "it's fine but not excellent" when I should have pulled away and explained that the main issues I have are about bitlocker as a user.

Have you never gone on vacation and forgotten your daily-use password upon return?

Nop.

Our helpdesk deals with 2-300 users per day that logon every single day yet forgot their password.

This type of thinking doesn't work in large enough orgs dealing with end users.

Having dealt with FileVault in this context, it's also frustrating; it's really common to have it fail to follow the logged-in user's credentials, and if you use any kind of federated login, you will frequently get users with FileVault passwords that are either ahead of or behind their system login password.

I think both approaches are valid trade-offs and I think that the default Secure Boot BitLocker configuration, for all its architectural tradeoffs, can probably be credited for an enormous amount of data loss mitigation originating from used hard drives alone.

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 capability to copy/paste.

Compare it to Vera/Filevault where the access key is the users passphrase. In MacOS it's literally your account password, which follows along with your in-OS account credentials.

Or nowhere you know at all if you're a non-technical user who was on a local account Win 11 setup who was tricked by microsoft dark pattern pop-ups getting you to go to "online accounts" which automatically and silently encrypts your drives in the background and then tells you to go to to some shady domain called aka.ms (with another computer, since yours is now locked on a bluescreen and unusable). Basically a typical ransomware message. In truth in this case it's #1 (uploaded to Microsoft) but the non-technical user doesn't know that. Even I thought aka.ms screen was ransomware when my parent called me saying their computer had a "virus".

That happens with Veracrypt as well. I have plenty of friends and family who can't remember their WiFi password without remembering where it was written down, and they use that far more often than an encryption recovery code.

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.

> Filevault for MacOS (which is wonderful and never sends your key to be kept somewhere else)

Did you read the documentation?

https://support.apple.com/guide/mac-help/protect-data-on-you...

"iCloud account: Click “Allow my iCloud account to unlock my disk” if you already use iCloud. Click “Set up my iCloud account to reset my password” if you don’t already use iCloud."

https://developer.apple.com/documentation/devicemanagement/f...

"FileVault Full Disk Encryption (FDE) recovery keys are, by default, sent to Apple if the user requests them. Only one payload of this type is allowed per system."

Can.

If you click "Allow my iCloud account to unlock my disk", your recovery key is escrowed to Apple, tied to your Apple Account.

If you don't select that option it never does.

I should have said "without your explicit permission", but I assumed we were all adults and understood that.

The main point is that it's using your account password to unlock, the recovery key is for if you forget your account password.

No, you were just plain wrong. You said “never”, when in reality BitLocker and FileVault both have optional escrow.

FileVault absolutely has an optional iCloud Keychain escrow. That’s how the “unlock with Apple Account” feature works. Apple doesn’t have the keys for iCloud Keychain, but it is still stored in iCloud.

We have more issues with FileVault than we do with BitLocker, the latter being a fleet 5 times larger than the former. I find both “fine” for enterprise.

Reply on news.ycombinator.com