VeraCrypt should adopt the macOS standard authentication dialog

[theprivacydesigner]

Current behavior

When VeraCrypt needs elevated privileges, it shows a non-standard dialog with one password field.

Desired behavior

VeraCrypt should adopt macOS’ standard authentication dialog (which offers both a username and password field).
This is particularly desirable for people using VeraCrypt in a non-admin account and who need temporary admin rights to perform an operation.

VeraCrypt’s password prompt

macOS’ standard authentication prompt

[idrassi]

Thank you for the report. Indeed, using the native macOS authentication dialog would be better.

The current VeraCrypt implementation on macOS still uses the common Unix elevation path based on sudo: VeraCrypt asks for a password and starts its internal core service through sudo. This is why the prompt has only one password field, and it also means that authentication is tied to the current user being allowed to use sudo.

Supporting the macOS dialog with both username and password is not just a UI change. The native Authorization Services flow doesn't give VeraCrypt the password to pass to sudo: it gives an authorization right. A proper implementation would require a macOS-specific privileged helper / launchd service, with strict request validation, so that VeraCrypt no longer handles the administrator password directly.

I consider this a valid enhancement, but it needs to be significant work because privileged helpers are security sensitive.

I will keep this issue open as a macOS enhancement. Contributions are welcome.

[damianrickard]

I took a pass at this. Opened a PR that replaces the macOS sudo elevation with a code-signed launchd privileged helper installed via SMJobBless, so VeraCrypt shows the standard macOS authentication dialog and no longer handles the administrator password itself: #1792

It reuses the existing core-service entry point (the helper validates the client's code signature, then spawns VeraCrypt --core-service as root over an XPC-provided socket), so the request/response protocol and all existing validation are unchanged. The helper only launches a root-owned binary from a non-user-writable install location, and per-connection client code-signature checks gate every request. Signing identity and Team ID are build-overridable with the IDRIX defaults committed. Tested end-to-end on Apple Silicon, including installing to /Applications and mounting a real external device and a hidden volume.

A few points for discussion are noted in the PR: keeping the deployment target at macOS 12 with SMJobBless vs. moving to macOS 13 + SMAppService; the trusted-install-location requirement (VeraCrypt must be installed, not run from a DMG, to elevate); and the Full Disk Access requirement for raw-device access (unchanged from the current sudo behavior). Feedback welcome.