35308 - password and encrypting protecting for mail folders

Status: RESOLVED WONTFIX

(MailNews Core :: Database, enhancement)

Description

[André Langhorst]

it should be possible to protect local (remote? if it´s possible) mail folders
with passwords, these folders should be encrypted then, to avoid that people can
read mail with a text editor

Comment 1

[Kevin Hecht]

Isn't this an OS file system security issue rather than a program issue? This is 
really only a problem on Win95/98 where file system security doesn't exist, and 
even there some third party encrypting utilities exist. On NT/2000 and Unix, 
file system permissions should take care of this problem.

Comment 2

[André Langhorst]

if w95/98 users shouldn´t be enabled encrypting folders and securing them with
passwords, one even had to write a mechanism which is completly different on
different platforms, and I don´t know if it is possible to secure a particular
file with winNT/2000 and on access to prompt for a password, and before, piping
the prompt to mozilla to let mozilla display that prompt,
I think it´s no filesystem issue even because not all os´s provide the same
functionality

Comment 3

[lchiang]

assign to bienvenu for comments or to mark helpwanted.

Comment 4

[David :Bienvenu]

reassigning to steve. This would be a help-wanted thing.

Comment 5

[Jerry Baker]

Oh jeez peoples. Mozilla already has an encryption engine built in.

Comment 6

[selmer (gone)]

Sure, encryption facilities are available.  A lot of design needs to be done and
some UI changes are implied.  This isn't going to make it into this release.
Anyone interested in helping??

Comment 7

[André Langhorst]

are there any docs describing how to get involved in designing mozilla interfaces?

Comment 8

[André Langhorst]

proposing mozilla1.1., adding ui keyword

Comment 9

[Aleksander Adamowski]

Kevin (responding to comment #1):
1. There are OS'es that have the encryption functionality built-in, there are
OS'es that have only access control, and there are OS'es that have neither. The
user frequently cannot choose an OS for the task at hand unfortunately...

2. OS's filesystem permissions are a different animal than encryption. They are
there to offer _access control_ - to stop unauthorized users of the system from
writing  or reading files, but they are of no use when the OS itself is
compromised. If someone can steal your notebook, boot it from a CD and bypass th
OS, there's nothing to stop him from reading those mail folders.


IMO, this feature would be very useful in Mozilla. My friend who will be stuck
on an untrusted Win98 machine for the next few days has asked me about this.

My suggestion would be to implement this on a per-account basis, where the
account's directory is an encrypted file containing all the underlying structure
(so that even folder names are encrypted).

Per-folder encryption could be also implemented as a separate, lower level
layer, but only if development resources allow (maybe implemented later in the
future, separately from account files encryption).

If we decide on implementing a fully comprehensible confidentiality system, then
I propose a multi-layer implementation:
1. Entire profile encryption (in the profile dir there is one big file being a
self-contained encrypted filesystem), possibly with the profile's password being
also used later in the chain as the Master Password in PSM
2. Mozilla's functional parts encryption (each Mozilla app can register for a
separate encrypted namespace to keep its files and folders, implemented as a
single physical file). The separate passwords for MailNews stuff (rules, account
settings, folders), Browser stuff (cookies, bookmarks, cache etc), Editor stuff
(a safe repository for confidential/copyrighted/commercial webpages being
developed?)
3. lower-level layers (application-specific, e.g. level3:MailNews accounts;
level4: per mailfolder encryption).

So what you say?

Comment 10

[Aleksander Adamowski]

BTW, see related bugs:
bug 98346
bug 16489
bug 19184

Comment 11

[Matthias Versen [:Matti]]

*** Bug 214281 has been marked as a duplicate of this bug. ***

Comment 12

[Josh Birnbaum]

*** Bug 322372 has been marked as a duplicate of this bug. ***

Comment 15

[Chett Salzman]

I think there is some misunderstanding of my request/idea.
So let me explain.

Here is an example. I let someone use my email clienty to send an email. or I walk away from my computer. I want to be a abler to locvk down a specific folder
in the email database so no-one can open that specific folder. Perhaps I having banking emails etc in that folder...someone tries to open it, and it requests a password. Outlook has this feature.and....not related to Windows security,
I don't know where that came from......also this is 8 years old...what took so long?

Comment 16

[zug_treno]

(In reply to comment #15)
> <..> that folder...someone tries to open it, and it requests a
> password.

It seems that this enhancement request asks for a similar feature, see the summary: "password and encrypting protecting for mail folders" and comment 0: "it should be possible to protect local (remote? if it´s possible) mail folders with passwords".

Comment 17

[Jonathan]

(In reply to comment #9)

What's the status of this bug? Is it planned for Thunderbird 3? Aleksander basically laid out exactly what needs to happen 6 years ago, and so far, it doesn't seem like anybody is interested in doing it.

Comment 20

[Carl Menezes]

Given that there has been no reply for bug status, I'd like to bump the question. Thunderbird 3 is out and this is still missing. Could somebody reply as to whether it is planned? This is extremely important.

Comment 21

[Andrew Sutherland [:asuth] (he/him)]

This is unlikely to ever be part of the core product.  Users with security concerns should store their profile on an encrypted partition using a mechanism suitable to their operating system such as 'truecrypt' and taking care to properly configure their operating system so as to not compromise the encryption (using un-encrypted swap or otherwise writing the contents of memory to disk in an unencrypted form, having the temporary files directory write to unencrypted disk, etc.).

Efforts to make mail storage pluggable in the medium term would make it more feasible for an extension to explicitly provide for encrypted mail storage without requiring OS-level hooks, but it is unlikely to ever provide as comprehensive a solution as placing the Thunderbird profile on encrypted storage and using a properly configured system.

Comment 24

[David McDivitt]

I just created a bug which Joshua pointed here. My text is below. It would be very easy to pass application reads and writes through freely available encryption routines. Little management would be required to start encryption and support reads and writes through routines.

***

I have my Thunderbird email on a TrurCrypt volume. After reading email I
religiously dismount the volume and back it up. Thunderbird files alone
represent 3.8 gig. It takes awhile to backup and verify. Having to mount and
dismount a volume is a nuisance. Please consider passing the reads and writes
for mailbox files only, not necessarily the index, through simple encryption
routines. When opening Thunderbird the password given would be the encryption
key. As with any encryption, the password would not be recoverable if lost and
people would have to be advised if the option is used. This would help me
because only changed files would have to be backup up rather than a huge
TrueCrypt volume. This would be relatively simple to implement. Thanks

Comment 25

[Andrew Sutherland [:asuth] (he/him)]

David, you may want to consider using a back-up solution that backs up the contents of your encrypted volume to another encrypted volume, rather than backing up the encrypted volume in its entirety.

(I believe that would also be better encryption hygiene; a hypothetical attacker with access to a before and after image of an encrypted volume would be able to derive some information from the blocks that changed (by inferring things from the amount of new/changed data and its placement in the volume).  If you have multiple copies of the volume from different time-points, even more information would be exposed.  In practice, this is not likely to be a major concern.)

As an update on my previous comments, pluggable mail storage should be landing on the trunk in the next few months after 3.3 branches, so if someone wanted to pursue an encrypted mail store as an add-on, they could do so and even start developing it now (the pluggable mail store patches are available).  That support will not affect the mork .msf indexes or the gloda global database (which will actually store the entire text contents of the messages if they are locally available), but it would be a start.  (And if you turn off gloda, the information in the mork store is pretty limited.)

Comment 26

[David McDivitt]

That's a good thorough analysis, Andrew. I still think it would be easy to run reads and writes through an encryption routine, and may still be a good feature to have, but you give me something to consider. It would definitely be faster to configure my sync program to do changed files only, inside the mounted volumes instead of outside.

Comment 29

[Lee Van Jackson]

duplicates still being found - really doesn't feel like this bug has been closed - see comments above! A real description of why its a wontfix is needed even if it is a serious can of worms or security hole. People are still asking for this!

Comment 30

[larrybird]

As this has been resurrected, would add that my original report 1222900, though similar, is specific to the use of smart cards or other cryptographic devices for encrypting of specific sent copies (locally stored).

Comment 31

[Magnus Melin [:mkmelin]]

-> WONTFIX per comment 21.