Bugzilla

Assignee

Comment 3

•

2 years ago

Note: You can get this feature as of today, using external gnupg to manage your secret key. See the thunderbird smartcard howto:
https://wiki.mozilla.org/Thunderbird:OpenPGP:Smartcards

This bug requests to implement optional individual passphrase protection directly inside TB, without having to depend on external GnuPG.

Assignee

Updated

•

2 years ago

Blocks: 1679455

https://support.mozilla.org/en-US/kb/openpgp-thunderbird-howto-and-faq#w_how-is-my-personal-key-protected

Comment 5

•

2 years ago

I suggest wontfix.

Whiteboard: [wontifx?]

mdedonno1337

Comment 7

•

2 years ago

I would like to know why thunderbird is not configured to use the gpg-agent on the system, letting gnupg make the signature/encryption, and hence letting him deal with the password expiration and management ?

Stefan Neufeind

Comment 8

•

2 years ago

@Kai: Thanks you mentioned how to use GnuPG instead (according to the Smartcard-howto). That looks promising for people who prefer to centrally use GnuPG on their system (possibly used by other applications as well) and not store keys separately in thunderbird.

My +1 to have separate password per key in the internal key-management of Thunderbird, like GnuPG uses it. And with a configurable cache-expiry for the entered password?

mozilla

Comment 9

•

2 years ago

I came here from a blog post about how to set a master password for Thunderbird in order to avoid storing the private key password in clear text.

I guess more people will stumble across this bugreport. I’ve written a blog post about how to avoid setting a master password and use the builtin GnuPG keyring instead. Check it out here, I am happy for every feedback!
https://blog.nicohood.de/use-thunderbird-78-with-system-gnupg-keyring

Gus Andrews

Comment 10

•

2 years ago

Bringing feedback from a meeting with the Internet Freedom Festival community:

Our Thunderbird user base works on human rights internationally as journalists, NGO employees, and activists. Many of them face arrest or confiscation and search of their devices.

For these users, not being able to depend on a strong unique password they have to enter themselves is literally the difference between life and death or loss of liberty. An attacker could easily confiscate their device and use the access to their email to build a case to keep them in prison or execute them, or pretend to be them, wreaking havoc on the trustworthiness of efforts to protect people worldwide.

We need the option to enter a password to encrypt and decrypt. In a community feedback session, a number of our users reported trusting Thunderbird less when they no longer had that option. Losing this option erodes user trust and is likely to lose Thunderbird a very dedicated userbase.

mdedonno1337

Comment 11

•

2 years ago

I have solved the issue by using the external GPG agent as follow:

Use the Thunderbird config editor (found at the bottom of preferences/options), and search for mail.openpgp.allow_external_gnupg. Set the value to true.

Enabling this preference will cause Thunderbird to attempt to decrypt a message using GnuPG, whenever the internal GnuPG fails to decrypt a message with the secret keys that are available inside Thunderbird's key storage.

Note: The private keys shall be removed from the internal Thunderbird keyring; only the public keys need to be there to enable the draft encryption. Moreover, we need to reconfigure the End-To-End Encryption settings for each account (setting the correct key ID).

Note: To be able to send an encrypted email, the public key of the recipient shall be present in the internal keyring of Thunderbird.

Note: It is not possible to use a expired key for signing. Moreover, the expiration is set per subkey: this means that, even if the main key is not expired, the encryption can not be done if the encryption subkey is expired. The default expiration change procedure only changes the main expiration date, and not the subkey one.

nf

Comment 12

•

2 years ago

Thunderbird has a Master Password feature than can protect secret key (and other sensitive info):

https://tails.boum.org/doc/anonymous_internet/thunderbird/openpgp_migration/index.en.html#master-password

Instead of (or before) reintroducing a key password, we could encourage people to set up a Master Password while setting up OpenPGP for their account. My understanding is that it would provide the same level of security of users at risk of physical threats. And it's already implemented :)

I'll mention this on the mockups that Ura is working on.

Ferenc Veres

Comment 13

•

2 years ago

As a user of these I'd add: the Master Password management window (list of saved passwords) does not indicate whether the OpenPGP automatic generated passkeys (that protect the GPG keys) are also protected by Master Password or not. They could even appear maybe there in the window and user would have the option to delete them.

And related discussion is the strength of Master Password implementation (bug linked below). If this is used the strength should be hopefully similar to use of GPG key passwords. (I've seen articles on the net stating FF/TB Master Password is very easy to bruteforce, so any short random password works as good as a long complex password: protects from those only who would read the plain text, nobody else. I can't find that reference. I don't know whether direct GPG key passwords are also prone to that or not.)

https://bugzilla.mozilla.org/show_bug.cgi?id=973759

Comment 14

•

2 years ago

(In reply to Gus Andrews from comment #10)

An attacker could easily confiscate their device and use the access to their email to build a case to keep them in prison or

a number of our users reported trusting Thunderbird less when they no longer had that option.

People in high risk environments need to take extra precaution, such as using full disk encryption. For a scenario where the attacker has physical access to your hardware and is willing to physically harm you, it's futile to discuss whether they would get access to your data. There's no way Thunderbird (or other applications) can protect you from that. It would be counter productive to let users think otherwise.

Comment 15

•

2 years ago

(In reply to nf from comment #12)

Instead of (or before) reintroducing a key password, we could encourage people to set up a Master Password while setting up OpenPGP for their account. My understanding is that it would provide the same level of security of users at risk of physical threats. And it's already implemented :)

Agreed, we should add a note to inform people about this option. Depending on your setup, you may or may not want to use it. It's far from "free" though: big time usability problems, lockout with no way to recover if you can't remember the password etc..

Oliver Kluge

Comment 16

•

2 years ago

A master password for TB is NOT the same as passphrases for accounts!

a) Because it is 1 master password for N mail accounts together instead of N passphrases
b) You force users to enter the master password EVERY TIME when they only want to read/write mail from mail accounts without passphrases, greatly (!) encumbering users.

Does no one think of users that have a multitude of mail accounts for different purposes, each being secured or not secured as necessary for that purpose?

If you want to make Thunderbird replace Enigmail, then introduce the same (!) or better functionality. Currently, Thunderbird offers more ease of use, at the loss of security. Let users make that choice!

Gus Andrews

Comment 17

•

2 years ago

(In reply to Magnus Melin [:mkmelin] from comment #14)

(In reply to Gus Andrews from comment #10)
People in high risk environments need to take extra precaution, such as using full disk encryption.

Absolutely. Our users know that. Those who are able to take that precaution do.

For a scenario where the attacker has physical access to your hardware and is willing to physically harm you, it's futile to discuss
whether they would get access to your data. There's no way Thunderbird (or other applications) can protect you from that. It would
be counter productive to let users think otherwise.

Having worked with this community for close to a decade now, I can tell you it's counterproductive to use the word "futile." We should not encourage anyone using encryption into a feeling of learned helplessness, lest they simply give up. We see that happen.

There's more use cases here than just "highly sophisticated attacker has physical access to your device." There's also "less-sophisticated attacker or malicious personal contact has momentary access to user's Thunderbird and uses it to send out defamatory messages." Many of our users share devices with their families or colleagues because they're in areas where procuring additional devices is prohibitively expensive.

Honestly, it's patronizing to talk about "letting users think otherwise." Users think what they think. They know their use cases better than we do as white, well-educated, Western longtime users of this technology. I would not necessarily have prioritized development of the option to enter a password when you send, but multiple users requested that in community events and user testing. I am adding their voices to this discussion because I think you, as the project manager who ostensibly prioritizes development of features for this software, need to hear them. Particularly in order to stave off abandonment of Thunderbird by a user base that has been loyal for years.

Giving the option to enter a password every time is, to some extent, a matter of making your users comfortable with the tool you develop. A product issue. Which perhaps should be deferred until Thunderbird hires a product manager, as I understand you are planning to do. This is not the kind of decision that should be left to devs.

nf

Comment 18

•

1 year ago

I think that we should reject this issue in favor of Bug#1741042, for which Kai already has a patch.

nf

Updated

•

1 year ago

Comment 19

•

1 year ago

(In reply to nf from comment #18)

I think that we should reject this issue in favor of Bug#1741042, for which Kai already has a patch.

There's a test build, if you'd like to try and give feedback.

Assignee

Comment 20

•

10 months ago

I've closed bug 1741042 and want to rather work on this one.

Assignee

Comment 21

•

10 months ago

After having been busy most of the TB 102 development cycle with other tasks, and after having mostly completed the work on bug 1627956, I'm trying a "last minute sprint" to make progress on this bug, and potentially get it included into the upcoming 102 release. I'm not sure if we will succeed, but let's try.

I'd like to try to implement the spirit of the request as good as possible, but given time constraints, I'd like to suggest a middle ground solution.

The solution I want to offer isn't based on what I consider ideal. It's based on pragmatism. It's what we might be able to implement quickly, and based on the technical constraints of our code.

The default configuration would remain as it is today.

However, users could set a global pref in private/security settings, independent of primary password, to enable the use of a separate passphrase for OpenPGP secret keys.
(In other words, it would be allowed to have any combination of primary password and OpenPGP passphrase enabled.)

If enabled, use a single OpenPGP passphrase for all OpenPGP secret keys managed by Thunderbird.
(Don't support separate passphrases for separate OpenPGP secret keys, to reduce UI complexity.)

If "separate-passphrase" option is configuration, we'd show an additional new user interface element, for example a button in the status bar.
The button would either say "OpenPGP secret keys are locked" or "OpenPGP secret keys are unlocked" (the latter with visual highlighting to indicate that you are in the "hot" state).

While unlocked, a single click on the button would immediately lock all your OpenPGP secret keys.

Locking could be manual (click the button), or automatic, with an additional option to lock automatically after N minutes. For users who are worried, I'd suggest a value of 1 minute. I wouldn't recommend a value of zero, because then you'd have to unlock again when replying to a message. But if there's demand, we could allow that immediate lock after use.

Unlocking can be done manually (click the button), or triggered automatically, when trying to read an encrypted message or trying to send a signed message.

For a person who needs maximum protection, the workflow could be:

start thunderbird, you're in locked state initially
click an encrypted message, it's shown as "cannot decrypt, keys are locked"
we might automatically trigger an unlock prompt
if user enters passphrase successfully, decrypted message is shown
user accepts that the keys remain unlocked, or know that it will be re-locked after N minutes,
or notice the visually highlighted "keys are unlocked" button,
and could click it to immediately lock it again

When locked, and you try to send a signed message, you'd have to unlock, too.

Would you consider this an improvement to what we have today?

Assignee

Comment 22

•

10 months ago

Attached file WIP: Bug 1679278 - work in progress. — Details

Assignee

Updated

•

10 months ago

Whiteboard: [wontifx?]

Assignee

Updated

•

10 months ago

Assignee: nobody → kaie

Comment 23

•

10 months ago

(In reply to Kai Engert (:KaiE:) from comment #21)

Hi Kai,
It is great that you're looking at this and I understand the constraints you have to work through/around.

The solution I want to offer isn't based on what I consider ideal. It's based on pragmatism. It's what we might be able to implement quickly, and based on the technical constraints of our code.

However, security is never something that should be done "as quickly as possible" ; just look at Masterlock padlocks! Please consider that this "bug" has been open for 2years + and so an extra year or so to have this architecture constructed safely and securely would be what everyone who is aware of this bug would prefer over a quick-n-dirty fix just to get this ticked off the neverending list of things to fix.

Locking could be manual (click the button), or automatic, with an additional option to lock automatically after N minutes. For users who are worried, I'd suggest a value of 1 minute. I wouldn't recommend a value of zero, because then you'd have to unlock again when replying to a message. But if there's demand, we could allow that immediate lock after use.

I would suggest that timed locking (typically 3- or 5- minutes without access to the PGP keys being made) should be a REQUIREMENT rather than an option, so that even if they wanted to, someone can not unlock their PGP emails, then go and make a coffee, disable their screensaver and have anyone access their PGP emails 24 minutes later.

The default configuration would remain as it is today.

...

For a person who needs maximum protection, the workflow could be:

I read between the lines here that fundamentally the broad overview even after many, many years still hasn't been updated - it should be EVERYONE needs maximum protection, but most people are unaware of it. Being unaware you need something doesn't mean you don't need it (like, you know, medication, or email security). I would gently ask that the point of view can be adjusted that EVERYONE needs maximum protection and then build workarounds (if you wish) for people who are the exception -- who DO NOT want PGP security on their Thunderbird-based emails.

start thunderbird, you're in locked state initially

-- YES

click an encrypted message, it's shown as "cannot decrypt, keys are locked"

we might automatically trigger an unlock prompt

-- The flow would be logical that this notice is displayed along with a prompt to enter the PGP key unlock passphrase.

if user enters passphrase successfully, decrypted message is shown

-- YES, further, (as I believe Enigmail did) if more than three bad passwords are given to unlock keys then an increment throttle timer is triggered (ie wait +10, +15, +20 seconds before retrying the master passphrase.

user accepts that the keys remain unlocked, or know that it will be re-locked after N minutes,

-- Keys should always be relocked X minutes after unlocking or after key access is required to decode a message. This can be set in a setting for example between 1 and 15 minutes or another maximum time, with recommended/default something under 10 minutes (5 is advisory)

or notice the visually highlighted "keys are unlocked" button,
and could click it to immediately lock it again

-- YES

When locked, and you try to send a signed message, you'd have to unlock, too.

-- YES

Further, and I use several keys; I would like an option whereby to use a particular key (once the TB cabinet is unlocked), I MUST enter the PGP passphrase itself, as well as the Thunderbird Cabinet code -- because then I am forced to enter the PGP passphrase and memorise it, else I will maybe remember the Thunderbird code (through repetition) but will gradually loose memory of the actual PGP passphrase itself because of never actually needing to write it in, this can be a massive headache (literally) when using something else using the same keys, such as Kleopatra etc.

Would you consider this an improvement to what we have today?

It is a tall order, but Thunderbird MUST store a locker of PGP Keys as securely as the PGP keys themselves are; else if thunderbird can access and use the keys and they're not securely stored this is a HUGE reduction in the safety of PGP (which, by all standards is STILL one of the safest protections available), therefore Thunderbird needs to secue the keys at that level.

Thanks again for updating us and looking into this large and nuanced topic.

Assignee

Comment 24

•

10 months ago

(In reply to Martin from comment #23)

just look at Masterlock padlocks!

What does that mean in this context?

Please consider that this "bug" has been open for 2years + and so an extra year or so to have this architecture constructed safely and securely would be what everyone who is aware of this bug would prefer over a quick-n-dirty fix just to get this ticked off the neverending list of things to fix.

I got the feeling that waiting for another year would be bad. The major deadline for a yearly release are the user interface strings, which need to go through localization, and we only do this effort once a year for the yearly release - and that deadline is end of next week. It the design of the user interaction can be completed by that time, the strings could be included, and a little more time could be taken to test the implementation - with the option to enable it in a 102.x release.

I read between the lines here that fundamentally the broad overview even after many, many years still hasn't been updated - it should be EVERYONE needs maximum protection, but most people are unaware of it.

There are users who would disagree with you. Some users might rather stop using encryption at all, than being forced to repeatedly be bothered to enter a passphrase.

Thunderbird is a flexible tool, and needs to offer a choice. Users need to decide if they want to rely on full disk encryption and OS lock (on a personal machine), or if they rather want to use a lock in Thunderbird (on a shared machine).

I understand that there are users who want to have repeated prompts for the passphrase, and locking after a short amount of time, and I'm fine to offer this functionality. It's an easier approval process with the Thunderbird product owners, if this functionality is optional, and not made a requirement for all users.

if more than three bad passwords are given to unlock keys then an increment throttle timer is triggered (ie wait +10, +15, +20 seconds before retrying the master passphrase.

thanks for this reminder

Further, and I use several keys; I would like an option whereby to use a particular key (once the TB cabinet is unlocked), I MUST enter the PGP passphrase itself, as well as the Thunderbird Cabinet code -- because then I am forced to enter the PGP passphrase and memorise it, else I will maybe remember the Thunderbird code (through repetition) but will gradually loose memory of the actual PGP passphrase itself because of never actually needing to write it in, this can be a massive headache (literally) when using something else using the same keys, such as Kleopatra etc.

I don't fully understand this, it's not clear to me what you're referring to by "TB cabinet code".
With the suggested implementation, the TB primary password (formerly called master password) would still be used to protect all application secrets like accounts passwords and the S/MIME secret key. If it's enabled, it must be entered on TB startup to login to servers.
If the new separate OpenPGP passphrase is configured, you'd be asked for that when required for decryption or signing, if you aren't yet in the unlocked state I've described.

Thunderbird MUST store a locker of PGP Keys as securely as the PGP keys themselves are; else if thunderbird can access and use the keys and they're not securely stored this is a HUGE reduction in the safety of PGP (which, by all standards is STILL one of the safest protections available), therefore Thunderbird needs to secue the keys at that level.

The keys would be managed by the RNP library, in a keyring file managed by that library. Thunderbird wouldn't re-invent that storage format.

Assignee

Comment 25

•

10 months ago

Maybe you weren't aware, but from what I saw from the latest version of Enigmail - it didn't force you to use any protection at all. You could set up Thunderbird 68, install Enigmail, and it would automatically create a key for you, without asking for any key protection at all. Adding a passphrase to protect the use of the OpenPGP secret keys was already optional at that time.

Comment 26

•

10 months ago

(In reply to Kai Engert (:KaiE:) from comment #24)

Further, and I use several keys; I would like an option whereby to use a particular key (once the TB cabinet is unlocked), I MUST enter the PGP passphrase itself, as well as the Thunderbird Cabinet code -- because then I am forced to enter the PGP passphrase and memorise it, else I will maybe remember the Thunderbird code (through repetition) but will gradually loose memory of the actual PGP passphrase itself because of never actually needing to write it in, this can be a massive headache (literally) when using something else using the same keys, such as Kleopatra etc.

I don't fully understand this, it's not clear to me what you're referring to by "TB cabinet code".
With the suggested implementation, the TB primary password (formerly called master password) would still be used to protect all application secrets like accounts passwords and the S/MIME secret key. If it's enabled, it must be entered on TB startup to login to servers.
If the new separate OpenPGP passphrase is configured, you'd be asked for that when required for decryption or signing, if you aren't yet in the unlocked state I've described.

To rephrase; I have several PGP keys each with their own passphrases. My understanding of your quoted message was that there would be a Thunderbird master password that would be used to access and use ALL keys within the access, and I had (erroneously) termed this the "TB Cabinet" -- so to use a TB passphrase to gain access to the PGP keys.

If this was what you meant, my thoughts on it was that there is a potential that users can add keys, memorise their TB master password and use that to deal with their keys without ever needing to remember the key's own passphrase. Thus in the fullness of time this may well be forgotten, I think it would be useful to (at least have the option) to confirm the key passphrase when using any particular key.

Apologies if my understanding of your post concept is awry.

Comment 27

•

10 months ago

(In reply to Kai Engert (:KaiE:) from comment #25)

Maybe you weren't aware, but from what I saw from the latest version of Enigmail - it didn't force you to use any protection at all. You could set up Thunderbird 68, install Enigmail, and it would automatically create a key for you, without asking for any key protection at all. Adding a passphrase to protect the use of the OpenPGP secret keys was already optional at that time.

I was not aware of that (or maybe I simply forgot it over time) but I would hope/assume that everyone with a PGP key would be understanding that the human is the weakest part of any security and set a passphrase accordingly.

Assignee

Comment 28

•

10 months ago

(In reply to Martin from comment #26)

I suggest to enforce that the same passphrase is used for all OpenPGP secret keys that are imported into Thunderbird (or generated by Thunderbird).

With this approach, if the user uses multiple keys for separate accounts, or has old revoked/expired keys in addition to current keys, entering a passphrase would be sufficient to make use of all your keys.

All OpenPGP secret keys are locked and unlocked at the same time.

This avoids having to prompt multiple times for passphrases. It avoids a user interface that has to explain what specific key the user is supposed to unlock. It avoids the complexity that users need to wonder which of their keys are unlocked and which ones aren't yet. It makes it possible to have a status indicator that says "secret keys are unlocked".

My hope is that this simplification is still a sufficient protection mechanism. If users really require separate passphrases for separate secret keys inside Thunderbird, they could use the Thunderbird profile manager to have two or more Thunderbird profiles.

Let me explain that again in the context of what is possible today, and in relation with the Master/Primary password setting. (For the remainder of this text, I will assume everyone of you is aware that the master password has been renamed to primary password).

Today, by default, you have no protection at all. This has always been the case in Thunderbird, even if you were using S/MIME secret keys.

Today, you already can enable the primary password. If you do, all your secrets will be protected. An automatically created passphrase is used to protect all of your OpenPGP secret keys, too. You currently cannot influence what that passphrase is. It's simply a level of indirection, because we must technically store the OpenPGP passphrases in a file that is separate from the other secret keys and account passwords.

With the suggested implementation, you'd have the option to enable the use of a separate OpenPGP passphrase. That would move the OpenPGP secret keys out of the scope of the Primary Password. This means, if the user has existing OpenPGP secret keys that were previously protected using the primary password, and the user discovers the new setting and enables the use of the "separate OpenPGP passphrase", we'd perform a migration to the new passphrase. We'd ensure the user has the main storage unlocked using the primary password, then we'd prompt the user for the new OpenPGP passphrase (with explanations), and then we'd change the protection of all existing OpenPGP secret keys: the protection by the previous automatic passphrase is removed, and the protection using the OpenPGP passphrase is activated.

A user could also decide to disable the primary password, and only use the passphrase protection for the OpenPGP secret keys.

Assignee

Comment 29

•

10 months ago

•

Edited

Because in comment 10 and comment 17 several example scenarios were given, and it was requested to have strong protection, for users who risk their life and their liberty, I think it's necessary to again describe what level of protection we're discussing in the scope of this bugzilla ticket.

For at risk users, who risk their life or their liberty, who must use a machine on which they cannot enable full disk encryption, the protection mechanism requested here will NOT protect them against an sophisticated attacker, who can confiscate the device while it's turned on, who can keep the confiscated device active, and who can do a forensic analysis of system memory to find copies of entered passphrases or secret keys (from a time when they were previously unlocked).

It means, users who are willing to risk life and liberty, need to be aware that having a passphrase for the secret keys as the only level of protection may only help against less sophisticated attackers, who only try to copy files found on the disk, or try to use Thunderbird interactively.

If we offer this functionality, will it be clear to affected users that this risk remains, and do you think the users would accept this remaining risk? Would they be willing to accept the risk, based on an assumption or hope that they'd only ever encounter less sophisticated attackers?

In my understanding, the intention of the request here is to provide a basic level of protection, that will help against simple attacks, only. It would protect encrypted data from a friend or colleague or family member who is allowed to use the same device, but who will not perform a forensic analysis, who will not collaborate with a sophisticated attacker, and who will not install a key logger. It would protect against a random person who is able to momentarily access your device and could be tempted to look at encrypted messages or use the device to send out digitally signed messages in your name.

Do we all agree on the scope?

Arvidt

Comment 30

•

10 months ago

(In reply to Kai Engert (:KaiE:) from comment #29)

For at risk users, who risk their life or their liberty, who must use a machine on which they cannot enable full disk encryption [...]

What are the scenarios for this?
I can only imagine that the user does not own the machine, does not have control over it.

I would urge to educate users whose life and liberty is at risk, not to make their life dependent on a foreign computer they do not control, even not at TB on their own (internet connected) computer at all.

As I had written in bug 1627956 comment 2
users with high security demand should be given an education text like
"Please create Your private key, compose and encrypt Your text on a plain installed seperate offline device (with a secure operating system like Tails and the recipients public key verified in person), and use internet connected TB only for transporting the offline encrypted attachment file."

See Snowden's magic carpet- that's professional. Noobs risking their life by using foreign machines or any other internet connected machines? Please no.

Assignee

Comment 31

•

10 months ago

Arvidt, the scenarios are shared machines, or machines that cannot use full disk encryption. Please read comment 10 and comment 17. I fully agree that it's dangerous to not use full disk encryption. But because computers are expensive, not everyone can afford a separate device for that.

We have been asked to provide this level of protection anyway, even if it isn't perfect.

Phabricator Automation

Updated

•

10 months ago

Attachment #9276982 - Attachment description: WIP: Bug 1679278 - work in progress. → WIP: Bug 1679278 - Bug 1679278 - work in progress.

Ferenc Veres

Comment 32

•

10 months ago

Thanks for the great explanations and working on this. As a long time PGP user, I think Kai's proposed solution in comment #21 is a good improvement over what Thunderbird has today. It gives an extra protection layer for those messages that are encrypted. While the TB is continuously open with a Primary Password.

If different keys would be encrypted with separated passwords, that would not make it more complex for users. You could let users set a password per-key while importing it (if this is technically possible in TB), and if one password cannot unlock all keys, then TB would silently unlock as many as it can. At time of opening one key (for reading or sending). If a message is opened which does not have an open key, it would ask for one more password. And possibly open one or more further keys again.

This way users could set the same password per-key as it is in their OpenGPG. (As Martin described.) (However noting that the keys and passwords will be then used on two totally different encryption mechanisms, which might weaken security.) (Martin: the original PGP passwords are not used by TB. They are removed and the keys are re-encrypted with another method and protected with automatically generated, fairly complex password. Which password is then protected by the Primary Password. Or not protected at all, if you have no Primary Password.)

The "lock indicator" would not need indicate whether one or all are open. Just open (one or more) or not open (none), and allow to close (all). (A tooltip might give more info.)

The "unlock indicator" could open the key which belongs to the currently selected account (plus silently more if they accept the same password). Or there would be no way to "manually open" them. Just at time of sending or reading, automatically. As I remember, that's how Enigmail worked and it was OK.

User may still choose to use one password, in that case user experience would be just as you described.

Regarding timeout: that sounds good. But when the timer would start? At time of entering the password? Or last use of any PGP key while working with TB? (I.e. reset timer with each use of a PGP key? In this case working with many encrypted messages is more convenient and similar to current behavior.)

Computer sleep or screen lock should also lock this.

Assignee

Comment 33

•

10 months ago

Attached file Bug 1679278 - Refactor to minimize entry points for OpenPGP secret key import. r=mkmelin — Details

Depends on D146779

Assignee

Updated

•

10 months ago

Keywords: leave-open

Phabricator Automation

Updated

•

10 months ago

Attachment #9277286 - Attachment description: WIP: Bug 1679278 - Refactor OpenPGP key import code to minimize entry points for secret key import. → Bug 1679278 - Refactor to minimize entry points for OpenPGP secret key import. r=mkmelin

Assignee

Updated

•

10 months ago

Keywords: checkin-needed-tb

Updated

•

10 months ago

Status: NEW → ASSIGNED

status-thunderbird_esr91: --- → wontfix

Target Milestone: --- → 102 Branch

Pulsebot

Comment 34

•

10 months ago

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/a621f83b8c42
Refactor to minimize entry points for OpenPGP secret key import. r=mkmelin

Keywords: checkin-needed-tb

Oliver Kluge

Comment 35

•

10 months ago

(In reply to Arvidt from comment #30)

I would urge to educate users whose life and liberty is at risk, not to make their life dependent on a foreign computer they do not control, even not at TB on their own (internet connected) computer at all.

I must in very strongest of terms reject the derogatory wording "urge to educate users". This must imply that such users are un-educated, or that you are in possession of a higher truth. This is the arrogance that drives ordinary users away from technology. Don't use such words. If you are not in a situation as such users are, do not judge their judgement. Didn't the thought cross your minds that there are situations where you must rely on foreign equipment because there is no alternative?

Comment 36

•

10 months ago

(In reply to Ferenc Veres from comment #32)

Regarding timeout: that sounds good. But when the timer would start? At time of entering the password?

Yes. The timer starts at the last point the system can prove the authorised human last accessed it -- ie by entering the keypass for the PGP key.

Computer sleep or screen lock should also lock this.

I agree. But this should be superceded by above, if nessecary.

(In reply to Oliver Kluge from comment #35)

(In reply to Arvidt from comment #30)
I must in very strongest of terms reject the derogatory wording "urge to educate users". This must imply that such users are un-educated, or that you are in possession of a higher truth. This is the arrogance that drives ordinary users away from technology. Don't use such words. If you are not in a situation as such users are, do not judge their judgement. Didn't the thought cross your minds that there are situations where you must rely on foreign equipment because there is no alternative?

Agreed. It's not Thunderbirds place to educate anyone. Not least without first understanding their situation.

Assignee

Comment 37

•

10 months ago

I suggest, let's skip the "who said what" and "who attempts to educate whom" part of the discussion.
We're listening. We're trying to help. We've started to work on this.

Comment 38

•

10 months ago

(In reply to Kai Engert (:KaiE:) from comment #29)

In my understanding, the intention of the request here is to provide a basic level of protection, that will help against simple attacks, only. It would protect encrypted data from a friend or colleague or family member who is allowed to use the same device, but who will not perform a forensic analysis, who will not collaborate with a sophisticated attacker, and who will not install a key logger. It would protect against a random person who is able to momentarily access your device and could be tempted to look at encrypted messages or use the device to send out digitally signed messages in your name.

Do we all agree on the scope?

Yes, while it's not going to be as strong as core PGP protection, it would allow Thunderbird to implement secured PGP encryption of messages.

The real risk with email communication is not the end device, but the transportation.... every single server node that handles an email can read its contents, and this as a factor is far more important than an end user . It also helps protect end users from server admins who can snoop into emails, because that does happen.

TL/DR: I am on Thunderbird 68 because I can't use V78+ until there's a suitable system for managing PGP in place that doesn't release my encrypted emails if my device gets stolen or my server gets compromised. So I would be looking forward to developments as described by Kai :)

Assignee

Comment 39

•

10 months ago

Martin, I'm not sure if you're fully aware of the functionality that Thunderbird 78+ ALREADY provides. In my understanding, Thunderbird already provides the functionality you're asking for.

If you set a primary password in Thunderbird, your OpenPGP secret keys will already be locked using that primary password, too. Assuming you don't have any unprotected backups of keys on your computer, and you have a primary password set, your secret keys are already protected if your computer is stolen (if the computer is locked or shut off).

A complaint that has been reaised is that the keys will remain fully unlocked for the remainder of the Thunderbird session,
and another request was the ability to use separate passwords, so a simpler primary password could be used for protection account passwords, and a stronger passphrase for the protection of OpenPGP secret keys.

This bug/ticket here is about the following improvements:

use a passphrase that is SEPARATE from the existing primary/master password mechanism
offer a way to LOCK AGAIN the use of your OpenPGP secret keys. After you have used them
to decrypt a message, go back to locked state, to require that the user must enter the
password again to decrypt.
Instead of locking after every decrypted message, my suggestion is to instead implement
an automatic timeout that can be configured to one minute, and will automatically lock
again after one minute, plus a new button on screen that can be used to lock immediately.

Comment 40

•

10 months ago

(In reply to Kai Engert (:KaiE:) from comment #39)

Martin, I'm not sure if you're fully aware of the functionality that Thunderbird 78+ ALREADY provides. In my understanding, Thunderbird already provides the functionality you're asking for.

As I understood when I used V78 when it came out ( a while ago now), the master password meant I didn't need to use the PGP passsphrases when writing an encrypted email. However my memory is imperfect and this is an aside to this bug discussion.

Assignee

Comment 41

•

10 months ago

(In reply to Martin from comment #40)

As I understood when I used V78 when it came out ( a while ago now), the master password meant I didn't need to use the PGP passsphrases when writing an encrypted email. However my memory is imperfect and this is an aside to this bug discussion.

Background:
You never need to use your secret for pure encryption, because when creating an encrypted message, your secret keys are not required.
However, the default is to send an encrypted and signed message. And for creating the signature part, your secret key is required.

Regarding master password:
If you have a master password set, and you have entered/unlocked using the master password on startup, then you don't need to enter the password again as long as Thunderbird is kept open.
That means that currently, if you send an encrypted and signed message, you don't have to enter the password again.

With the suggested improvement in this bug, if you will activate the separate passphrase for OpenPGP secret keys, and if you activate the timeout, and the timeout has passed, or you have manually locked, then you would be required to enter your passphrase again for sending an encrypted and signed message.

(You would be never be prompted for sending an encrypted but not signed message, because pure encryption doesn't require the use of your secret keys.)

Assignee

Comment 42

•

10 months ago

... and of course, the same applies for decrypting a message. After the timeout has passed and your secret keys were locked automatically, or if you have locked them manually, you'd also have to enter the passphrase again for decrypting a message.

Assignee

Updated

•

10 months ago

Summary: Thunderbird: Allow the optional use of user defined OpenPGP passphrases → Thunderbird: Support a separate, user defined OpenPGP passphrase, and the ability to relock secret keys after use

Assignee

Comment 43

•

10 months ago

Attached file Bug 1679278 - Land strings that will be required for the OpenPGP passphrase feature. r=aleca — Details

Assignee

Comment 44

•

10 months ago

I made a mistake in the refactoring patch. One function rename is done in the main patch, and needs to be backed out.

Assignee

Comment 45

•

10 months ago

Attached file Bug 1679278 - Revert parts of refactoring to fix a regression. r=mkmelin — Details

Phabricator Automation

Updated

•

10 months ago

Attachment #9276982 - Attachment description: WIP: Bug 1679278 - Bug 1679278 - work in progress. → WIP: Bug 1679278 - work in progress.

Pulsebot

Comment 46

•

10 months ago

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/7af9f75b4d27
Revert parts of refactoring to fix a regression. r=mkmelin

Assignee

Updated

•

8 months ago

Severity: -- → N/A

Priority: -- → P2

A

Comment 47

•

4 months ago

(In reply to Magnus Melin [:mkmelin] from comment #14)

People in high risk environments

Forget about high risk environments. Why does the UX of the OpenPGP implementation in Thunderbird not replicate Enigmail exactly?

I have a number of users on Thunderbird 76(?) which I am unable to upgrade, precisely because of these differences. I though I was good to go after stripped key support was finally implemented, but now this is another showstopper.

A

Comment 48

•

4 months ago

(In reply to Kai Engert (:KaiE:) from comment #28)

(In reply to Martin from comment #26)

I suggest to enforce that the same passphrase is used for all OpenPGP secret keys that are imported into Thunderbird (or generated by Thunderbird).

With this approach, if the user uses multiple keys for separate accounts, or has old revoked/expired keys in addition to current keys, entering a passphrase would be sufficient to make use of all your keys.

No, no, no, no.

Using multiple keys is precisely how I know that I am sending from the right account, encrypting with the right key, and actually committing the act of signing the message (in my neck of the woods, the legal act of signing requires a positive action).

All OpenPGP secret keys are locked and unlocked at the same time.

This avoids having to prompt multiple times for passphrases. It avoids a user interface that has to explain what specific key the user is supposed to unlock.

This is precisely what I need, what I expect, and what it used to be like. Why would you force me and my users to re-learn something that they had been using successfully for close to seven years now.

It avoids the complexity that users need to wonder which of their keys are unlocked and which ones aren't yet. It makes it possible to have a status indicator that says "secret keys are unlocked".

What complexity? Can you point to one bug report that says "I can't use OpenPGP because I don't know which keys are unlocked"?

My hope is that this simplification is still a sufficient protection mechanism. If users really require separate passphrases for separate secret keys inside Thunderbird, they could use the Thunderbird profile manager to have two or more Thunderbird profiles.

😳

I have two email addresses from two different companies (in addition to my own private email). Are you really suggesting that I should restart Thunderbird with a different profile depending on which account I want to send email from?

Today, by default, you have no protection at all. This has always been the case in Thunderbird

Not true. This didn't happen with Enigmail.

An automatically created passphrase is used to protect all of your OpenPGP secret keys, too.

Why was this done? I can't think of a single reason why this would be a good idea. If you want "convenience", just remove the passphrase.

With the suggested implementation, you'd have the option to enable the use of a separate OpenPGP passphrase. That would move the OpenPGP secret keys out of the scope of the Primary Password. This means, if the user has existing OpenPGP secret keys that were previously protected using the primary password, and the user discovers the new setting and enables the use of the "separate OpenPGP passphrase", we'd perform a migration to the new passphrase. We'd ensure the user has the main storage unlocked using the primary password, then we'd prompt the user for the new OpenPGP passphrase (with explanations), and then we'd change the protection of all existing OpenPGP secret keys: the protection by the previous automatic passphrase is removed, and the protection using the OpenPGP passphrase is activated.

You lost me here. What is the Primary Password? Is that the same as Thunderbird's master password? Or the "let's use the same made-up passphrase for all PGP keys" mechanism that you mention above? And is the above paragraph describing a one-off migration (back to what it used to be in the first place for those of us who actually used OpenPGP) or is this some kind of repeated process?

A

Comment 49

•

4 months ago

(In reply to Gus Andrews from comment #17)

Sorry for the noise, but I agree with much of Andrews' comment. To summarise:

They know their use cases better than we do

That is so indeed.

Particularly in order to stave off abandonment of Thunderbird by a user base that has been loyal for years.

That is also so. It has been a low priority task of mine to migrate users to an email client that meets our requirements since the demise of Enigmail (TB 72? 67? I forget) meant that newer versions of TB are no longer adequate for our needs, and the compliant version is getting long in the tooth.

Giving the option to enter a password every time is, to some extent, a matter of making your users comfortable with the tool you develop. A product issue.

I'd say it's more than a matter of comfort. It's a matter of making Thunderbird usable again, for existing users.

Which perhaps should be deferred until Thunderbird hires a product manager, as I understand you are planning to do.

Product manager or product owner? Either way, not sure a green newcomer to the project would help in any way. On the other hand, you sound like the sort of chap that could be useful in that position.

This is not the kind of decision that should be left to devs.

I am puzzled by the fact that the existing OpenPGP implementation is so different from Enigmail, which was the standard, time-tested tool that we were all using. Is it documented anywhere why the functionality was not exactly duplicated?

Something else that I wonder is if any of those involved in the development of the Enigmail replacement do actually use signing and encryption themselves. I'm not talking about simply signing / encrypting out of habit, but for instance approving expenses or concluding contracts simply by replying with a signed email (as opposed for instance an unsigned reply seeking further clarifications, negotiating, etc.)

Please don't just make stuff up. Go out, physically meet and talk to users, find out what their actual needs are, not what you think those are.

Assignee

Comment 50

•

4 months ago

If independent passphrases per secret key are preferable, we can consider to offer that approach instead.

The master password feature has been renamed to primary password in newer versions of Firefox and Thunderbird, it's the same thing.

I understand your frustration that Thunderbird now behaves differently than Enigmail, but we had no choice.
I don't want to justify, just mention a few of the reasons.
The Enigmail developer was no longer able to continue to maintain it, because of Mozilla platform architectural changes, driven by Firefox, which Thunderbird developers couldn't influence, but which Thunderbird developer were required to adopt.
And because of licensing issues, Thunderbird could no longer use GnuPG as the default underlying OpenPGP engine.
And time was very short to create an alternative implementation.

In case you didn't know, it's possible to use GnuPG as an alternative engine for secret keys.
This way, locking/unlocking secret keys is driven by GnuPG.
It requires manual configuration. This page describes how to do so:
https://wiki.mozilla.org/Thunderbird:OpenPGP:Smartcards

A

Comment 51

•

4 months ago

(In reply to Kai Engert (:KaiE:) from comment #50)

If independent passphrases per secret key are preferable, we can consider to offer that approach instead.

For my use case, they're more than preferable: they are a must.

Please note that the secret keys are used in multiple places, not just Thunderbird but also for document signing, instant messaging and for some users (I think, not sure) remote login. While some of my users are technically savvy enough to understand that they might have to use different passphrases in different software / devices, I can assure you they're not going to be amused.

The master password feature has been renamed to primary password in newer versions of Firefox and Thunderbird, it's the same thing.

Thanks.

I understand your frustration that Thunderbird now behaves differently than Enigmail, but we had no choice.
I don't want to justify, just mention a few of the reasons.

Thanks, I was aware of the architectural issues (XUL deprecation, was it?) but my question was about why the functionality (aka UX) was not replicated? Because of time constraints, I guess?

And because of licensing issues, Thunderbird could no longer use GnuPG as the default underlying OpenPGP engine.

I wasn't aware of that.

[ Details for the next reader: TL;DR: Thunderbird's MPLv2 is not compatible with OpenPGP's GPLv3+ and devs didn't want to make gpg a dependency (source: https://www.zdnet.com/article/thunderbird-to-add-built-in-support-for-openpgp-email-encryption-standard/). ]

In case you didn't know, it's possible to use GnuPG as an alternative engine for secret keys.
This way, locking/unlocking secret keys is driven by GnuPG.
It requires manual configuration. This page describes how to do so:
https://wiki.mozilla.org/Thunderbird:OpenPGP:Smartcards

That didn't work during my first migration attempt a couple of years back but I'll give it another go, thanks.