Security model

Security model

VaultBar is a front end for macOS's own encrypted disk images. It adds no cryptography of its own.

The password

• Never stored: not on disk, in the Keychain, in the config, in logs, in process arguments, environment variables or the clipboard.
• It reaches hdiutil attach -stdinpass (and diskutil image --stdinpassphrase create for new vaults) only through a pipe on the child process's stdin, closed right after writing.
• An empty password is refused before any tool runs, so the system's own disk-image password dialog (with its "Remember password in my keychain" box) never appears.
• Password bytes are zeroed after use. Best effort: the Swift String the text field hands over can't be wiped from memory.
• The popup has no "remember" option and nothing is saved between unlocks.
• The command line and the URL scheme have no password parameter: unlocking always means a person typing into the popup.

Encryption

• New vaults are AES-256 APFS sparse bundles, created and opened by macOS (DiskImages). Add Existing accepts any encrypted .sparsebundle or .dmg (VaultBar only checks that it is encrypted). VaultBar only starts and stops them.
• Unencrypted images are rejected by Add Existing Vault….

What auto-lock protects against

Auto-lock closes the window in which an unlocked vault is readable by someone at your Mac or by a process running as you: it locks on sleep, screen lock and idle. The screen-lock and idle locks re-check before forcing, so a vault is not force-detached once you are back.

It does not protect an unlocked vault from software running as you while it is unlocked, and Pause auto-lock deliberately removes the idle and screen-lock locks for an hour (sleep still locks).

Ways to shrink that exposure: read-only mounts (nothing can be written), a private mount hidden from Finder (out of file pickers; the folder exists only while unlocked), and the panic hotkey (everything locked in one keystroke). See also Where plaintext can leak.

Config and logs

• ~/.config/vaultbar/vaults.json has mode 600 and holds only names, image paths and settings.
• Lock, unlock and pause events are logged with the vault name and reason (errors from writing Raycast scripts or the login item include the error text, which can contain a folder path), under the com.padina.vaultbar subsystem:

log show --predicate 'subsystem == "com.padina.vaultbar"' --info --last 1h

Notifications and history

Notifications never name a vault, because they can show on the lock screen. The History window (last 50 events, with vault names) is kept in memory only.

Network

VaultBar makes no network connections.

Limits

• No password recovery. Lose the password and the data is gone.
• Change password re-wraps, it doesn't re-encrypt. Change Password… uses diskutil image --stdinpassphrase chpass (both passwords on stdin) and then checks that the new password opens the image. The data key stays the same, so copies of the image made before the change (Time Machine, snapshots, other backups) still open with the old password. For a full re-key, create a new vault and copy the files across.
• Not notarized; releases are self-signed with a stable identity, so permissions survive updates (not notarized, so first launch still needs Open Anyway). The source is open; you can build it yourself.
• A vault is only as safe as its password: VaultBar warns below 12 characters.

Reporting a vulnerability

See SECURITY.md in the repo.