TL;DR: There is a gap in being able reset the password to the account when a user has lost access to all devices, temporarily or permanently. Trusted contact(s) can be used to decrypt the data. "Emergency access" will work, but is overkill as it provides the trusted contact(s) more access then is needed and may not be timely enough depending on the hold down timer selected well before the emergency. The dependency on the trusted contact(s) having a Proton account is a level of friction that hinders adoption. The rest of the Proton provided recoveries require off-site backup, which is unrealistic to expect the large majority of end-users to be successful executing.

Summary of Key points:
- (Simplified) The level of protection for authenticating to the Password Manager dictates access to all other resources.
- The scenarios under discussion here are trying to solve for "recovering" access to Proton Pass when the password is lost. Reframe this to "Can Proton do a better job of recovering access to Proton accounts?" I think yes.
- The only way to gain resilience beyond what is already there is to have an "off-site" recovery.

@Proton - your "Proton Account recovery explained" is a great document. It also clearly explains the limitations of those methods. Kudos. I think there is an opportunity for some content and/or wizard driven dialogs users setup the account properly in order to be able to recover. The nuances are a lot to ask of users. Even having a background in this area, making sure I configure everything correctly so as not to shoot myself in the foot would be great.
https://proton.me/support/set-account-recovery-methods

Between fires, floods, loss/theft while traveling and the PC at home is to far away to recover the data WHEN needed. Also consider that when the "trusted contact" is the partner/spouse and will often be sleeping in the same house (subject to fires/floods), taking the same trips (all luggage gets stolen), that an additional "off-site" contact should be selected. Someone or someone(s) that will likely never be in the same place at the same time. This extends to scenarios as extreme as the scenarios of the device is confiscated or impounded. Especially since Proton puts a lot of effort into scenarios such as journalist, aid worker, etc. safety. This is a nuance that most users would over look and might be nice to see Proton include it in any setup assistance they write.

- (GAP) Complete loss of access to devices (or logged in sessions): And practically, it isn't just devices. As very few people have e-mails/phone numbers memorized now that we all store them in the phone. A "sandbox" access scenario, where the user can get in via an alternate authentication path (username/password). It would be highly scoped access allowing the user to initiate communications with specifically identified trusted contacts. Specifically, enough access to an account to initiate a request to a pre-defined e-mail address/phone number to send a "force log off" or "password reset" request. The login wouldn't need to give access to the trusted contact's e-mail or phone number, just send the request. Even better would be to send an emergency message (like a temporary phone number). I realize that compromise of this scenario could be a social engineering attack vector... But so can theft/confiscation of the phone/computer and the current recovery methods.. Whereas, it does provide novel value of helping someone who has lost access to their electronically stored contact information engage with their trusted contacts (something that I haven't found other solutions).

Very important feature
For Pass and Authenticator

Yeah. Having the Authenticator decoupled from the rest of the Proton ecosystem is essential. Currently using Bitwarden as a result.

That's one of the most important features, most users are asking for it, so why isn't anyone paying attention? Does Proton see things so differently?

+1

Is it an option to create a shorter password for "pass" and "Authenticator" using a str-replace

Long password for mail, vpn wallet etc "firstPassPart.SeccondLongPart"

The shorter password for "Pass" and "Authenticator" like "firstPassPart.##" where ## is replaced by "SeccondLongPart" to the complete long password

It provides a short(er) password for pass, a sufficiently long password for the database encryption

I just posted a similar idea about partitioning data that takes this a good bit further, but this is exactly the kind of thing I am concerned about. Using a master password for universal access, while convenient, should at best only get your foot in the door if you wish to have enhanced security. Partitioning beyond that, or even working around that master password so that it can truly remain as a skeleton key, would both be improvements in a similar direction that would be very meaningful to me.

For a privacy and security oriented organisation like Proton it basically baffles me that you have to use your account's master password for logging in into everything.

Having an independent password like 1Password as mentioned before would be better as that would not potentially compromise your account.

(I use 1Password for storing the Proton account credentials because the password is nearly impossible to remember unless one has a photographic memory, but even then typing it out would be a hassle.)

so +100 for this request, and it should be implemented into all Proton apps, not just Proton Pass.

I should **NEVER** be expected to type my master password into a website. It should always **ONLY** be entered into an installed extension or mobile app, and ideally one that isn't auto-updated.

If you require users enter their master password into a website, you are putting users at risk of DNS attacks, compromised server infrastructure attacks, etc. While syncing an encrypted database to the cloud is certainly useful and should be retained, user should not be fetching client code from a server regularly (outside of user-controlled updates through a highly secured update system).

Training users to enter their master password into a website is a great way to encourage users to get phished as well. If they only ever enter their password into a mobile app or browser extension, they are much less likely to be phished.

Essa atualização precisa ser feita o mais rapidi possivel

The biggest problem is that Proton does not even bother answering or commenting...
Once you have paid, just Fxxxx off !

Please... I need a master password option rush.

A password manager secured with a shared password - LOL

OMG PLEASEEE. SOOOO IMPORTANT

I am a Proton Unlimited user. Would like to switch to using Proton Pass from 1P. However, in order to login to Proton Pass, it seems (1) you have to have your Proton password memorized and use a separate 2FA app such as Proton Authenticator (if enabled), or (2) use a recovery phrase. Or, (3) you would have to use another password manager for your Proton credentials and 2FA, which defeats the purpose of switching to Proton Pass.
With 1P, there is a secret key and then a Master Password, so you never run into this problem. So, it seems like it would make sense to have a separate login method for Proton Pass that is different from other Proton credentials.
Has there been anything published by Proton on best practices in the current scenario? Or any word on a resolution being implemented?
Thanks!

Hi Proton-Team! I think it will be similar to the proposal here: https://protonmail.uservoice.com/forums/953584-proton-pass-authenticator/suggestions/48633443-log-into-proton-pass-directly-with-its-own-passwor
I just switched from 1PW to PP. Like the user above, I am dealing with the problem of choosing between a very secure password for web access and a human-like password (some phrase, etc.) directly into the application. Similar to how 1PW works. This would even allow me to enter a second password on PP via a browser (maybe this already works this way, I haven't tried it).

This is the key problem of having an online password manager. I need to authenticate to it in a human-compatible way but it also has to resist automated unauthorized access. I'm not going to remember an actually really strong password and I'm likely to lose or damage any physical tokens used for 2FA. How can this be resolved?

With an offline password manager, at least there is the barrier of having access to the offline password database in the first place, so the passphrase to open the password database can be human-compatible without excessive risk of unauthorized access.

Even with a hybrid model (core credentials kept offline, frequently used / less critical credentials kept in Proton Pass) I always worry when Proton Pass needs my **core Proton Account password** to access it, the same password that also opens my Proton Mail and Proton Drive etc. that are much more sensitive than what I keep in Proton Pass.

Another way of saying the above: Proton Pass requires a password that opens it, while I only store in Proton Pass much less sensitive information compared to every other Proton app that requires the same password.

At a minimum, Proton Pass needs to accept a different password than the Proton account password... but I don't think that's good enough to fully trust Proton Pass to secure all of my credentials.

Yeah I don't know haha.

Is having access to the offline password database exactly equivalent to demonstrating access to a physical token or OTP key? (where would you store the OTP key reliably while you can still generate OTPs?)

still the most critical feature to separate the danger and prevent the deadlock !!!

I wanted to switch over to proton pass from bitwarden but I didn't because of this issue.

To second what John Doe said: The Deadlock Problem -- This feature becomes critical when you fully commit to the Proton ecosystem.
Here's the scenario: You follow best security practices and generate a long, complex password for your Proton account. Naturally, you store it in Proton Pass. But now you have a circular dependency. To access Proton Pass, you need your Proton password. To retrieve your Proton password, you need Proton Pass.

This creates a genuine deadlock situation, especially in disaster recovery scenarios where you might be logging in from a new device without any cached sessions.
The workaround today is to either memorize your Proton master password (defeating the purpose of a password manager) or store it somewhere outside of Proton (defeating the purpose of a unified ecosystem).
Allowing Proton Pass to have its own independent unlock method (a separate PIN, passphrase, or biometric) would solve this elegantly. It would let users safely store their Proton credentials inside Proton Pass without risking a lockout.
For users who trust Proton with everything, this is not a convenience feature. It is essential.