Closed Bug 1741042 Opened 3 years ago Closed 3 years ago

Allow manual or time-out based locking of the OpenPGP secret keys (decrypt/sign requires user to unlock with primary password)

Categories

(MailNews Core :: Security: OpenPGP, enhancement)

Product:
MailNews Core
Component:
Security: OpenPGP
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: KaiE, Assigned: KaiE)

References

Details

Attachments

(1 obsolete file)

Some users prefer to require a password prompt more frequently, if an OpenPGP secret key operation is performed.

We could define a new preference value to define a timeout.

By default, the timeout can be zero, which disables the timeout (a single authentication will work for the entire session).

In a first step (this bug), this could be done without user interface, to possibly allow backporting to the stable branch.

The user may use config editor to configure the desired timeout value (e.g. 60 seconds).

In a second step (a follow-up bug), we could consider to add user interface to configure the timeout.

Summary: If a primary password is set, and an optional pref is set, require password to perform OpenPGP secret key operation → If a primary password is set, and an optional timeout pref is set, require password to perform OpenPGP secret key operation

Thanks for opening this ticket Kai!

It looks like an elegant solution to Bug#1679278 and the fact that some of the at-risk users that we've interviewed complain about the lack of passphrase to protect their emails. As much as I understand the technical arguments of Magnus on Bug#1679278, entering a passphrase to decrypt emails is also a matter of feeling safe and in control, and understanding the underlying encryption mechanisms. Emotions are not to be overlooked when we're talking about the security of at-risk users. In some cases, users might choose a different tool that feels more secure even if it's less secure in reality.

For example:

  • On https://thunderbird.topicbox.com/groups/e2ee/T3c405032c441d8b1/thunderbird-91-3-0-and-openpgp-e2ee-email-encryption, the OP wasn't sure whether the emails were encrypted on disk because they were displayed without additional action by the user.
  • A digital security trainer from Zimbabwe shared with us that: « I totally support [the need for key password] and this is the main reason that
    most of the orgs are now looking for other encryption solutions.... It’s now FEELING SAFE which needs to be addressed here. Never underestimate the power of entering that password to decrypt an email. It’s powerful for some users to FEEL like they’re in control and on top of protecting their sensitive communications. »
  • A human-right defender from Colombia told us: « Now you need to have faith in the fact that it's encrypted. I don't like it that I lost control when I click on a message on whether it decrypts it or not. For me it's also an important educational aspect to have to enter a passphrase to be able to see the actual email. »

I think that we should reject Bug#1679278 if we go this route.

See Also: → 1679278

I tested some scenarios on Linux and macOS: "0", "1", "10", signing, and decrypting.

Everything went fine, the integration of the password prompt is good on both OSes. I love it!

Magnus was worried this might cause new issues with multiple master password prompts.

It would be good to run with this patch for a longer period, to see if the worry is correct.

I'm running the patch myself, have configured a timeout of 2 minutes, and I cannot confirm the worry. I once left the prompt open, and waited for a while, but it still didn't cause additional prompts.

(In reply to nf from comment #2)

It looks like an elegant solution to Bug#1679278 and the fact that some of the at-risk users that we've interviewed complain about the lack of passphrase to protect their emails. As much as I understand the technical arguments of Magnus on Bug#1679278, entering a passphrase to decrypt emails is also a matter of feeling safe and in control, and understanding the underlying encryption mechanisms. Emotions are not to be overlooked when we're talking about the security of at-risk users. In some cases, users might choose a different tool that feels more secure even if it's less secure in reality.

You're right we should not disregard feelings, even if they are misplaced. We could do a better job at educating users of what we do and what we don't so that they are informed and can take appropriate action.

A password prompt doesn't really solve that, even if it may feel so. We could add a password prompt to any unencrypted mail as well - it would be no more encrypted than it is in reality.

  • A digital security trainer from Zimbabwe shared with us that: « I totally support [the need for key password] and this is the main reason that
    most of the orgs are now looking for other encryption solutions.... It’s now FEELING SAFE which needs to be addressed here. Never underestimate the power of entering that password to decrypt an email. It’s powerful for some users to FEEL like they’re in control and on top of protecting their sensitive communications. »

I'd suggest adding more educational text somewhere (maybe E2E account settings or/and setup).
A timeout would also not solve it, because then you still don't have that control. It would have to be one-time usage for the pwd.

  • A human-right defender from Colombia told us: « Now you need to have faith in the fact that it's encrypted. I don't like it that I lost control when I click on a message on whether it decrypts it or not. For me it's also an important educational aspect to have to enter a passphrase to be able to see the actual email. »

"faith in the fact that it's encrypted" - I don't know what this is about. You can get an encrypted email from anyone who happens to know your key. If it's encrypted or not at the time of reception (reading), that is something the receiver has absolutely no control over. If they are educating that a password is needed to see an encrypted mail, I think they are educating wrongly.

See Also: → 1662272

By "faith", I think that this person referred to the increased opacity and the diminished feeling of control, and thus security, that comes from the fact that Thunderbird opens encrypted emails without further interaction and little visual feedback. With Enigmail, some at-risk users felt more in control (and some of them more secure) because they had to enter their passphrase to see the content of emails. TB 78 took this control away and some of the feeling of security that comes with it. To be clear, I understand how irrational this might be from a technical point of view.

To put this in context, this participant explicitly mentioned training people in South America to handle reports of human-rights violations on computer shared with many members of their extended family.

I don't think that this comes from being "educating wrongly". And even so, it's our job to help users build a correct mental model of the underlying crypto and educate them better, when needed, as you suggested. Until then, we shouldn't discard these feelings or their understanding of our tool as being wrong.

I still feel much more scared when I'm floating very high above ground in an airplane even though I perfectly know that I'm much safer in an airplane than driving a car. Airline companies spend lots of money on helping us feeling more secure because it's good for us and ultimately good for their business. Some of this is pure emotional design, without actual added security. Logic and emotion don't always go well together, and not because our feelings or our education are wrong. It's our job to also design for them.

Regarding doing a better job at educating users ourselves, I'm linking this ticket to Bug#1662272, which would solve some of this participant's concerns, I guess.

I think it is a valid scenario to have a shared computer, if a family or community only has a single computer available.

Yes, it is not secure to rely on the master password alone, but it takes criminal energy to install a key logger, and in some environments, the person needing security might safely assume that the other community members aren't sufficiently technically skilled to hack them. (Family with non-technical parents.)

In my opinion it is reasonable to optionally offer this functionality to users who wish to use it.
Thunderbird is all about offering poweful configuration options, so I don't see why we shouldn't offer this one, if it can serve some users.

I think we should have an OpenPGP FAQ entry that documents this feature, and clearly states the disadvantages and insufficienies and limitations, and then it's up to users to decide.

For example, this feature will be painful to use if you have automatic message filters, which in the future may support automatic decryption, and this won't work - instead Thunderbird will block waiting for the password.

Magnus, I'd like to kindly ask you to reconsider based on the arguments from comment 8.

Flags: needinfo?(mkmelin+mozilla)

Because of implementation details and unrelated required changes to the backend code (bug 1749391), the current suggested patch (on demand unlocking after timeout) would no longer work.

Should we ever consider this again, I think it will be necessary to combine with this some visible unlock action - instead of on-demand prompts.

For example, the UI could have a visual indicator somewhere that the OpenPGP secret keys are currently locked. After a configured timeout (as suggested by this bug), the visual indicator could switch to locked automatically. When locked, and when trying to access encrypted data, the content should show an appropriate error message (cannot decrypt, please unlock). The implementation could trigger the unlock. But we'd require new code, that re-runs the original user action (e.g. loading a message, signing), because of the technical limitations, the underlying code could no longer simply wait (block) for the password to be entered.

I'm not convinced that this is good UI, nor do I say that we should implement it. (We might not implement anything at all, given Magnus' concerns.) I'm just saving my thoughts on a potential future approach, that could work with our new backend code limitations.

It should be very possible to create a MailExtension experiment that just locks/unlocks when the user clicks it. (Except for that, there are other technical complications, like you wrote.)

Users who would like such functionality can then install it, and accept that this model of operation will not work for every case - and that if they use it they need to accept that.

Flags: needinfo?(mkmelin+mozilla)
Summary: If a primary password is set, and an optional timeout pref is set, require password to perform OpenPGP secret key operation → Allow manual or time-out based locking of the OpenPGP secret keys (decrypt/sign requires user to unlock with primary password)

During the usability tests, I asked the test participants what they particularly liked or disliked about OpenPGP in Thundebird. 3 participants out of 7 mentioned the lack of password.

I mentioned this already in some other thread on the same issue:
My main password is orders of magnitude less secure, than the one used to protect PGP.
So having to enter the main password is good, but I still prefer to have to enter my PGP passphrase to unlock my PGP key.
The current thunderbird behavio4r feels, like if thunderbird has hijacked my PGP passphrase...
Regards
Martin

The approach of the attached patch isn't ideal. It doesn't allow the user to set their own password separate from the master password (as requested in comment 14), and it's difficult to lock just the automatic OpenPGP password, as it would lock the stored mail account passwords as well. I think we should abandon this approach, and rather work on bug 1679278.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
Attachment #9250590 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: