Change FileVault password without changing login pw

[PTR916]

Hello!

I have the question above, so now both my login pw and FileVault pw is "123".
I'd like to keep my login password "123" but change my FileVault password to "456". How do I do this? Should I disable FileVault then turn in again and I'll have to option to setup a password for that? Or am I missing something? Can't find the solution for this.
Thanks in advance

 

[Rigby]

You cannot set an independent Filevault password for the boot volume, but you can do the following:

1) Create a dummy user account and set its password to "456"
2) Check the Filevault settings and make sure that the dummy user is enabled to unlock the disk
3) Remove your main account from the list of users that can unlock the disk: type "sudo fdesetup remove -user <username>" in Terminal
4) Disable automatic login: https://support.apple.com/en-us/HT202842

You can now unlock Filevault with the "456" password. After booting you'll be prompted to log in and can use your main account and password for that.

 

[grahamperrin]

Is the intention to disallow access to your home directory by administrators other than you?

 

[Weaselboy]

I'd like to keep my login password "123" but change my FileVault password to "456". How do I do this?

https://www.cnet.com/news/how-to-change-an-encrypted-volumes-password-in-os-x/

You can change the FileVault password using the diskutil command in Terminal. Just follow the instructions in this article.

Afterwards when you boot you will need to enter both the FileVault password to unlock the drive, then the user account password to login to the account.

Backup before you do this just to be safe.

 

[KALLT]

@Weaselboy: I don’t believe this applies to FileVault. It never gives you the passphrase that you need for this, only a personal recovery key. FileVault keeps the passphrase to itself and encrypts the information it needs with the recovery key(s) and password of the user account(s) instead.

 

[Alrescha]

FileVault keeps the passphrase to itself and encrypts with the recovery key(s) and password of the user account(s) instead.

FileVault volumes can be opened over a Firewire or Thunderbolt connection using Target Disk Mode using the login password. I suggest they are the same as any other core storage encrypted volume.

A.

 

[Weaselboy]

@Weaselboy: I don’t believe this applies to FileVault. It never gives you the passphrase that you need for this, only a personal recovery key. FileVault keeps the passphrase to itself and encrypts the information it needs with the recovery key(s) and password of the user account(s) instead.

Hmmm... could be. You are thinking it would not make the Keychain FV passphrase changes?

Searching around, I'm seeing posts that this works on a FV boot volume. Substituting the real UUID of course.

diskutil cs changeVolumePassphrase UUID

 

[grahamperrin]

There's the 2012 Apple technical white paper, Best Practices for Deploying FileVault 2. Also in the Internet Archive Wayback Machine: http://web.archive.org/web/*/http://training.apple.com/pdf/WP_FileVault2.pdf (I expect the original training document to become outdated before 2018).

 

[KALLT]

TL;DR: I’ve tried the command myself and it does not work. Always ends with ‘Error: -69886: Invalid request’ (whatever that means).

I believe the answer can be found on page 26 et seq. of the mentioned white paper. Basically, FileVault uses a chain of encryption keys to keep the whole thing configurable and extensible.

A user password is used to generate a so-called ‘derived encryption key’ which itself encrypts another key that FileVault needs (the ‘key encryption key’). Each user password will generate such a derived key and each one of these keys can decrypt that next key in the chain. I believe that the user password, the personal recovery key and the passphrase all have the same purpose to that end. The system only needs one of these derived keys to start the unlocking chain and does not care about the username (that’s apparently only for cosmetics in the pre-boot login screen).

A normally set up FileVault volume uses one or more login passwords and one personal recovery key for the derived keys. An encrypted CoreStorage volume uses a passphrase instead. What diskutil cs changevolumepassphrase/passwd (they are synonymous) does, is change the passphrase. FileVault does not use a passphrase. The command can simply not be invoked because of this. Instead, you would have to change the user password or the personal recovery key with sudo fdesetup changerecovery -personal.

When you enter the command sudo fdesetup list -extended, it will show you what you can use to unlock the disk. Whereas FileVault shows ‘Personal Recovery’ and ‘OS’ as the types, an encrypted CoreStorage volume would show you ‘Disk Passphrase’ instead.

 

[Rigby]

A user password is used to generate a so-called ‘derived encryption key’ which itself encrypts another key that FileVault needs (the ‘key encryption key’). Each user password will generate such a derived key and each one of these keys can decrypt that next key in the chain. I believe that the user password, the personal recovery key and the passphrase all have the same purpose to that end.

Correct, but the user passwords *are* the passphrases in the context of the boot volume (i.e. the DEKs are derived from the passwords of the users that are authorized to unlock the disk). The recovery key is randomly generated and then used to derive yet another DEK. Then for each of these DEKs, an encrypted copy of the next-level key (KEK) is stored on the disk.

On non-boot volumes, you can have a single, user-independent DEK that is generated from a separate user-created disk password.

The system only needs one of these derived keys to start the unlocking chain and does not care about the username (that’s apparently only for cosmetics in the pre-boot login screen).

Not quite. The user name tells the boot loader which of the encrypted KEK copies to use.

A normally set up FileVault volume uses one or more login passwords and one personal recovery key for the derived keys. An encrypted CoreStorage volume uses a passphrase instead.

Correct (although technically the boot volume is a CoreStorage volume too). The Mac OS tools don't allow the creation of a separate disk password for boot volumes AFAIK. You also cannot deauthorize all users from unlocking the boot volume in Filevault, i.e. at least one user password can always unlock it.

The bottom line is that the decryption keys for the boot volume are tied to user passwords. This is why I proposed the creation of a dummy user above. You just have to make sure that the regular user account is deauthorized in Filevault, otherwise the disk can still be unlocked with that user's password.

 

[KALLT]

Correct, but the user passwords *are* the passphrases in the context of the boot volume (i.e. the DEKs are derived from the passwords of the users that are authorized to unlock the disk). The recovery key is randomly generated and then used to derive yet another DEK. Then for each of these DEKs, an encrypted copy of the next-level key (KEK) is stored on the disk.

They ultimately fulfil the same function to create the derived keys, but with ‘passphrase’ I distinctly mean ‘Disk Passphrase’, which is the term fdesetup uses.

Not quite. The user name tells the boot loader which of the encrypted KEK copies to use.

FileVault doesn’t seem to care. You can try it yourself. I’ve tested it with two users and a personal recovery key from Recovery. It only prompts you to enter ‘a password’ and unlocks, it does not ask you for a username. I suspect it simply tries to decrypt each of the keys it has with what you’ve entered.

Correct (although technically the boot volume is a CoreStorage volume too). The Mac OS tools don't allow the creation of a separate disk password for boot volumes AFAIK. You also cannot reauthorise all users from unlocking the boot volume in Filevault, i.e. at least one user password can always unlock it.

As a matter of fact, you can remove all users from the list, as long as you still have your personal recovery key. At least that how it used to work. FileVault does seem to have a mechanism to remove a passphrase from an encrypted CoreStorage volume after ‘properly’ enabling FileVault, but it seems that Apple does not provide the reverse mechanism.

The bottom line is that the decryption keys for the boot volume are tied to user passwords. This is why I proposed the creation of a dummy user above. You just have to make sure that the regular user account is deauthorized in Filevault, otherwise the disk can still be unlocked with that user's password.

I didn’t want to discredit your solution, just comment upon the suggestion to change the passphrase. I actually agree with Graham that we need to know what the OP wants to achieve in the first place.

 

[Rigby]

As a matter of fact, you can remove all users from the list, as long as you still have your personal recovery key.

I just tried. fdesetup just says "Unable to remove user" when you try to remove the last one.