Closed Bug 1872542 Opened 2 years ago Closed 2 years ago

Although the primary password is asked when starting the application, if you select "Cancel" it opens the application revealing the emails and all the content even though the password was not provided.

Categories

(Thunderbird :: Security, defect)

Thunderbird 115
Desktop
Windows 11
defect

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1566458

People

(Reporter: vdw57120, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36

Steps to reproduce:

  1. Set a primary password for thunderbird desktop app
  2. Exit the app
  3. Select the thunderbird shortcut to open the app
  4. The primary password is asked
  5. Click Cancel

Actual results:

Although the password is not provided and I select "Cancel" it still opens the application revealing all my email accounts and all the content. Then the pop-up for providing the password re-appears. However, I can still see all the email accounts and navigate through the application by choosing "Cancel" every time in the pop-up.

Expected results:

The application content should have been protected from unauthorized access, since the primary password was not provided.

OS: Unspecified → Windows 11
Hardware: Unspecified → Desktop

The primary password protects only the saved passwords, not the cached data.

Group: mail-core-security
Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Duplicate of bug: 1566458
Resolution: --- → DUPLICATE

This is not a correct behavior!!! Where does it say that?? When you add a primary password in an application the obvious expected behavior is not to open the app unless the password is provided.

If you need the data to be protected, use full disk encryption.
Even if thunderbird would close, the data is easily accessible from the file system.

I read all the discussion in the bug marked as duplicate of this one: https://bugzilla.mozilla.org/show_bug.cgi?id=1566458
After I read this what I understood was that despite what you are saying about the file system, there would be a development for at least shutting down the application unless the password is provided and maybe add more steps for "forget password" etc.
Also, in a proposal it said "That prevents others from the ability to view messages or addressbook, and would require an aggressive move of copying message folders for viewing elsewhere."
I am not sure if the second part is actually feasible, but at least the first part I understood that it would be actually implemented. No?

Right, we're considering it yes.

Ok.
Also, regardless of this functionality, there is another related UX problem.
If you click "Cancel" the pop-up keeps showing up multiple times no matter how many times you click on "Cancel". And this does not happen only if you click on an encrypted message (if this was the case, then the PP would act as a "passphrase" to unlock encrypted emails) but in any navigation you do on the app.

I can see two usages of the "primary password" currently in place (and one usage that is not applied) and this might be one cause of the confusion:

  1. the "primary password" serves as a global passphrase for encrypted emails (as this is what I'm getting from what I've read and noticed while using the app). For this, you could:
    a. rename the "primary password" to something like "Global passphrase for encrypted emails", explaining that this serves as a main passphrase for applying the keys and automatically decrypt the encrypted emails.
    b. add a setting like "ask for global passphrase once when application starts or ask per email". If the user selects to be asked when starting the app, then ask them once at this point and this is it. Else, ask for the passphrase when clicking the "decrypt" on an encrypted email.

  2. the "primary password" serves as a "master password" to protect the "saved passwords" from being revealed. This is also the description in the section for the "primary password" inside the app. This seems to work fine when you click on "Saved passwords". I am saying "master password" because in this case, it acts like the master password in password manager applications.

  3. when opening the application the "primary password" is asked. In almost every other application, when this happens, the user assumes that they are asked for a password to unlock the app and open it. This is the general "login process". So, this could be named "application password" or something like that. In this case, the user expects for the application to shut down unless the password is provided (for example: keep prompting for the password or close the app if the user clicks "Cancel"). This functionality is not actually implemented.

Trying to apply the first two but giving the impression that you are falsely applying the 3rd is a bad UX.
The "primary password" naming is quite generic and thus confusing, especially when combined with all those 3 cases.

Thanks

You need to log in before you can comment on or make changes to this bug.