[dijit]

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.

[john_strinlai]

>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

[dijit]

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".

[bri3d]

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.

[john_strinlai]

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)

[dijit]

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.

[john_strinlai]

>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?

[dijit]

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.

[LtWorf]

You don't have remote back ups enabled?

[technion]

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.

[dcrazy]

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

[LtWorf]

Nop.

[akerl_]

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.

[dcrazy]

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.

[IrishTechie]

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.

[Arainach]

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?

[dijit]

"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.

[superkuh]

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".

[Arainach]

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.

[j16sdiz]

> 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."

[dijit]

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.

[dcrazy]

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