Skip to main content

Better FDE Passphrase with macOS FileVault

I use full disk encryption (FDE) on all my laptops and portable media. I like to have a very strong passphrase for these, one that is even stronger than that for my user accounts. Let's be realistic, very very few people are going to use a 60 character passphrase for their daily account, but I wouldn't mind using that to unlock my laptop since I only have to enter it so rarely (and I go through customs a lot). With the Mac, there isn't a nice built in way to have a long unlock passphrase for FileVault and a more reasonable one for day to day use of the laptop. However, we can use the features we have in the OS to make this happen.


  • User 1 ("unlock") used solely to unlock the disk. This user has a long, secure passphrase. You won't use the device as this user. This user does not need to be an administrator.
  • All other users, the day-to-day user(s) has a more manageable passphrase. At least one of these users is an administrator.

Summary of steps:

  1. Create an "unlock" standard user with a looooong passphrase
  2. Allow the "unlock" user to unlock the disk
  3. Reboot and confirm access via "unlock" user
  4. Disallow the day-to-day user from decrypting the disk


1. Create the "unlock" user.

a. Go to the System Preferences and click on "Users & Groups". The user does not need to be an administrator. I made my user a "standard user" so even with the correct passphrase to unlock the drive a second account is needed to administer the system. There really isn't an extra burden as you aren't going to be running as the "unlock" user anyhow.

b. Create the "unlock" user and select a loooooooooooong passphrase (DO NOT LOSE THIS!). 

2. Allow the new user to encrypt the disk.

a. Go to System Preferences and click on Security & Privacy.

b. Click on Enable Users

c. Click on "Enable User".

d. Enter the long passphrase for "unlock".

e. Ensure the green check mark is shown.

3. Reboot

a. Confirm you can login as the "unlock" user.

b. Logout of the "unlock" user and back into the account that has administrative access.

4. Disallow the day-to-day user from decrypting the disk

a. Open the terminal and type the following (replace "redsiege" with your day-to-day username):

sudo fdesetup remove -user redsiege

b. Repeat 4a for other users on the system EXCEPT "unlock"

c. Reboot and confirm. Unlock the disk with "unlock" and the long passphrase, logout of "unlock", then login as your normal user and works as usual!


You can now user a really long passphrase to protect your data when your laptop is powered off and booted. This is really nice if you have to cross any borders and want to make the passphrase that secures your data much better. Bonus points if you change the long passphrace, leave the data with a trusted individual, then ask athe trusted source for the info once you get through customs. That way customs can't make you decrypt the data since you can't!


Popular posts from this blog

Extracting Users from LinkedIn via Burp

We do a lot of pen tests and red teaming at Red Siege. Part of reconnaissance includes gathering a list of employees from a target organization. Typically, those usernames will be used in either phishing or password spray attacks (trying a few passwords across a long list of users). LinkedIn is a treasure trove of information! I'm going to use my good friends at Black Hills Information Security as my guinea pigs (sorry, and thanks!). The tool is here. First, let's look at what the data from LinkedIn looks like a response.

After performing a search for "Black Hills Information Security" we can look at the requests and responses. LinkedIn includes all the user information in responses to "/voyager/api/mux".

We can click the "Next" button a few times in our search to load multiple pages of info. Now, for the extraction. First, select everything in the "HTTP history" with Ctrl+A or Command+A on macOS. Second, right click in the top portion. …

Beyond Net User - Part 1: Limitations of the "Net" commands

I've had a number of cases where the Windows "net user", "net group", and "net localgroup" have failed me. I've had SQLMap fail to give the last line of "net user" output, I've had "net group /domain" not give me the full names (I still don't get how that failed!). On top of that, the commands don't support wildcards. Also, the output of those commands is a pain to parse due to the columns. I'd much prefer to use the AD PowerShell cmdlets, but those aren't always available. I set to find other ways to get the same data. First, let's look at the limitations of the "net" commands.
Net command limitations Hiding Groups in Groups Often when pen testing and red teaming, we would like to figure out information about the domain, most notably the members of the Domain Admins group. Output of the net group "domain admins" command as shown below.

It shows three members: Administrator, sqlagent,…

Beyond Net User - Part 2: DS Commands

In the previous post we discussed some of the limitations of Net commands. Most notably, the output limitation (doesn't show all groups) and it doesn't allow for flexible searching. In this post we'll discuss the DS commands to get around these limitations.
DSGet, DSQuery, DS* While these tools are useful, they aren't always available. As a pen tester and red teamer, I have to live with what I can find on the systems I come across. I find that these tools are still more widespread than the latest PowerShell Active Directory cmdlets, at least on non-system administrator systems. Here is a useful Stack Overflow post on the subject. Recursive Searches In the last post, we discussed a limitation in net group in that it doesn't show groups in other groups. The DS commands do! As a reminder, let's take a look at what we saw with net group when looking at the list of domain administrators.

Now let's do the same search, but use the dsquery and dsget.
dsquery group -…