Skip to content

[feat][security] Proton Pass: Require password on launch option#509

Open
Themistoklis wants to merge 2 commits into
ProtonMail:mainfrom
Themistoklis:proton-pass-launch-password-required
Open

[feat][security] Proton Pass: Require password on launch option#509
Themistoklis wants to merge 2 commits into
ProtonMail:mainfrom
Themistoklis:proton-pass-launch-password-required

Conversation

@Themistoklis

@Themistoklis Themistoklis commented Jun 2, 2026

Copy link
Copy Markdown

Description

As a well-known quote says:

Too much security is bad security

For a password manager, security needs to be strong enough to protect the user, but ergonomic enough that users do not work around it (UX / security tradeoff).

Current lock options use the same unlock method for launch and auto-lock. This creates an awkward tradeoff:

  • Password lock is secure, but can become annoying during normal use because it is required after each auto-lock (including minimizing the app in the tray for the desktop app).
  • PIN or no lock is convenient, but a browser/desktop restart may only require PIN or no unlock at all (insecure).

In practice, I wanted the app to always require my password after launching the desktop app or reopening the browser extension after closing the browser. The only available way to approximate that today is to enable password-based auto-lock. In my testing, that made normal usage disruptive: I had to type my password 7 times in the first 30 minutes of using the desktop app, and 3 times my PIN for the browser extension in the same timeframe.

Manual logout is another possible workaround, but it is easy to forget in normal usage. Most of the time, I would just close the browser or desktop app and assume the next launch would require my password (or turn off the computer with all apps still open). That makes the current behavior easy to misunderstand and creates a gap between the security users expect and the security they actually configured.

Users need a middle ground: strong protection when the app starts, without changing the normal auto-lock experience (if any) while they are actively using the app.

Feature

Add a checkbox in Security settings, below “Auto-lock after”:

✅ Require password on launch

When enabled:

  • Opening or launching the browser extension or desktop app requires password unlock first.
  • After the app is running, normal auto-lock behavior remains unchanged and follows the selected “Unlock with” mode.

Example:

  • “Unlock with” is PIN.
  • “Require password on launch” is enabled.
  • Launch asks for password.
  • Later inactivity auto-lock asks for PIN.

When 'Require password on launch' is enabled, the session data is encrypted using a KDF based on that password, not a local key. This ensures no bypass is possible.

Note: A rollback attack on the session secure blob to an older version where this option is not enabled will bypass it.

Disclaimer

The code changes were prepared with AI assistance.

I provided the feature direction and security requirements, and checked the secure parts to the best of my knowledge.
The resulting PR is the implementation of my plan, not a reviewed security design.

Because this touches authentication and local unlock behavior, it should be reviewed as security-sensitive code. In particular, please review:

  • the launch-password requirement cannot be bypassed by editing normal settings/cache;
  • enabling/disabling the option requires password confirmation;
  • extra password / backup password / second password flows are preserved;
  • launch password lock does not change normal auto-lock behavior;
  • extension and desktop launch paths both default to requiring the password when the state is unknown.

@mmso mmso force-pushed the main branch 5 times, most recently from 115579e to b6fd253 Compare June 3, 2026 16:16
… from the 'unlock with' feature. That enforces a password request on startup of your browser for the extension and startup of the pass desktop application
@Themistoklis Themistoklis force-pushed the proton-pass-launch-password-required branch from cf9cf41 to 6803d3f Compare June 5, 2026 16:17
@mmso mmso force-pushed the main branch 8 times, most recently from 25168a8 to 97c88ca Compare June 12, 2026 09:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant