dovecot - Oct 2022 - Dovecot mail-crypt webmail can't read encrypted messages

Sometimes not. If the data stored in mail accounts is more valuable than 
the server and control over it.

So this means passwords cannot be masked/hidden in the logs? You realize 
that it actually defeats the whole idea of encrypted storage? It's 
useless. I can think of lots of scenarios: malicious system 
administrator reading users mails and blackmailing them or selling their 
business secrets to competitors, corrupt law enforcement in some 
countries getting rid of political or business opponents by disclosing 
the contents of their mails and I can go on and on and on... There is no 
such thing as semi-privacy. Privacy is either there or it's not.

What exactly Dovecot does to hide passwords in logs?

I've studied mail-crypt plugin's docs and it's written there:

Also, it might be visible in debug logging. Suggested approaches are 
base64 encoding, hex encoding or hashing the password. With hashing, you 
get the extra benefit that password won?t be directly visible in logs.

So how can I make passwords to be not directly visible in logs?

On 2022-10-09 11:39, Aki Tuomi wrote:
> If you have intruder that is able to enable logs for your server, then
> you have bigger issues than someone enabling logs to see passwords.
> 
> Dovecot does it's best to hide passwords in logs, but unfortuntely
> this isn't perfect.
> 
> Aki
> 
>> On 08/10/2022 23:49 EEST Serveria Support <support at
serveria.com>
>> wrote:
>> 
>> 
>> Hi,
>> 
>> I'm here with a follow-up. I have managed to fix this issue!
>> 
>> I have rebuilt the entire project from scratch, using vanilla versions
>> of Dovecot, Postfix, SOGO webmail etc and everything works as 
>> expected:
>> emails are getting encrypted, I'm able to send, receive and read 
>> emails
>> in webmail. I suspect the root of the issue was that I was using
>> software package called iredmail. My guess is that all the master 
>> admin
>> drama was caused by iredmail. Big thanks to you guys for the hints and
>> ideas which eventually helped me troubleshoot this issue! I appreciate
>> your assistance.
>> 
>> P.S. Btw, is there any way to hide plain text passwords from Dovecot 
>> log
>> files? Disabling auth debugging won't help as the system may get
>> compromised and the intruder can re-enable logs and grab the passwords
>> from the logs. The only person who should know/see the password in 
>> clear
>> text should be the respective mail user. Is there any way to achieve
>> this?
>> 
>> On 2022-09-15 08:16, Aki Tuomi wrote:
>> >> On 14/09/2022 19:34 EEST Serveria Support <support at
serveria.com>
>> >> wrote:
>> >>
>> >>
>> >> Thanks for your help. Do you know in which folder the keys are
stored?
>> >> I'd like to check the permissions...
>> >>
>> >
>> >
>> > Some notes here, after reading this thread again:
>> >
>> > - Keys are stored in mail_attributes file, which depends on your
>> > config, but usually is %h/dovecot-attributes, which means
it'll be in
>> > user's home directory.
>> >
>> > - The key format is Dovecot Dcrypt Key, you can use `doveadm
mailbox
>> > cryptokey export` to export them in PEM format. Only **global
keys**
>> > expect PEM formatted keys, which you are not using.
>> >
>> > - If you are using mail_crypt_private_password to encrypt the user
>> > key, you will need to provide this every time you want to access
the
>> > user's emails, including using doveadm. Dovecot does not know
what
>> > password you are using.
>> >
>> > - Your logs indicate that you are, still, using master userdb.
This
>> > will not work. You cannot use master users with per-user
encryption
>> > passwords in the way you do. If you want to use master users /
master
>> > password, you must not encrypt the user key.
>> >
>> > - You should really focus on reading your logs, because they
really do
>> > indicate that the userdb_mail_crypt_private_password is not
exprted in
>> > anywhere, so clearly and obviously you are not able to access the
>> > mails.
>> >
>> > Maybe consider removing the master user authentication completely?
>> >
>> > Aki

> On 09/10/2022 12:53 EEST Serveria Support <support at serveria.com>
wrote:
> 
>  
> Sometimes not. If the data stored in mail accounts is more valuable than 
> the server and control over it.
> 
> So this means passwords cannot be masked/hidden in the logs? 
Passwords are hidden in logs, mostly. Debug logging unfortunately can leak some
password information.
> You realize 
> that it actually defeats the whole idea of encrypted storage? It's 
> useless.
Dovecot mail crypt plugin is primarily intended for securing storage, especially
one that is remote, like NFS or object storage. It is not intended for securing
your server against malicious admins.

In production use, customers usually use a site-wide global keypair to encrypt
the information stored in non-local storage.
> I can think of lots of scenarios: malicious system 
> administrator reading users mails and blackmailing them or selling their 
> business secrets to competitors, corrupt law enforcement in some 
> countries getting rid of political or business opponents by disclosing 
> the contents of their mails and I can go on and on and on... 
Yes, and mail crypt plugin is not intended for protecting these cases. 
> There is no 
> such thing as semi-privacy. Privacy is either there or it's not.
> 
> What exactly Dovecot does to hide passwords in logs?
> 
Turn on auth_debug=yes and see, you'll see passwords being masked.
> I've studied mail-crypt plugin's docs and it's written there:
> 
> Also, it might be visible in debug logging. Suggested approaches are 
> base64 encoding, hex encoding or hashing the password. With hashing, you 
> get the extra benefit that password won?t be directly visible in logs.
> 
> So how can I make passwords to be not directly visible in logs?
> 
Aki

Use hex encoding, base64 encoding or hashing the password, as it says. E.g.
%{sha256,salt=%{user}:password}. Directly using user's password for mail
crypt keys is unsafe anyways, due to % being an expansion character.
> On 2022-10-09 11:39, Aki Tuomi wrote:
> > If you have intruder that is able to enable logs for your server, then
> > you have bigger issues than someone enabling logs to see passwords.
> > 
> > Dovecot does it's best to hide passwords in logs, but unfortuntely
> > this isn't perfect.
> > 
> > Aki
> > 
> >> On 08/10/2022 23:49 EEST Serveria Support <support at
serveria.com>
> >> wrote:
> >> 
> >> 
> >> Hi,
> >> 
> >> I'm here with a follow-up. I have managed to fix this issue!
> >> 
> >> I have rebuilt the entire project from scratch, using vanilla
versions
> >> of Dovecot, Postfix, SOGO webmail etc and everything works as 
> >> expected:
> >> emails are getting encrypted, I'm able to send, receive and
read
> >> emails
> >> in webmail. I suspect the root of the issue was that I was using
> >> software package called iredmail. My guess is that all the master 
> >> admin
> >> drama was caused by iredmail. Big thanks to you guys for the hints
and
> >> ideas which eventually helped me troubleshoot this issue! I
appreciate
> >> your assistance.
> >> 
> >> P.S. Btw, is there any way to hide plain text passwords from
Dovecot
> >> log
> >> files? Disabling auth debugging won't help as the system may
get
> >> compromised and the intruder can re-enable logs and grab the
passwords
> >> from the logs. The only person who should know/see the password in
> >> clear
> >> text should be the respective mail user. Is there any way to
achieve
> >> this?
> >> 
> >> On 2022-09-15 08:16, Aki Tuomi wrote:
> >> >> On 14/09/2022 19:34 EEST Serveria Support <support at
serveria.com>
> >> >> wrote:
> >> >>
> >> >>
> >> >> Thanks for your help. Do you know in which folder the
keys are stored?
> >> >> I'd like to check the permissions...
> >> >>
> >> >
> >> >
> >> > Some notes here, after reading this thread again:
> >> >
> >> > - Keys are stored in mail_attributes file, which depends on
your
> >> > config, but usually is %h/dovecot-attributes, which means
it'll be in
> >> > user's home directory.
> >> >
> >> > - The key format is Dovecot Dcrypt Key, you can use `doveadm
mailbox
> >> > cryptokey export` to export them in PEM format. Only **global
keys**
> >> > expect PEM formatted keys, which you are not using.
> >> >
> >> > - If you are using mail_crypt_private_password to encrypt the
user
> >> > key, you will need to provide this every time you want to
access the
> >> > user's emails, including using doveadm. Dovecot does not
know what
> >> > password you are using.
> >> >
> >> > - Your logs indicate that you are, still, using master
userdb. This
> >> > will not work. You cannot use master users with per-user
encryption
> >> > passwords in the way you do. If you want to use master users
/ master
> >> > password, you must not encrypt the user key.
> >> >
> >> > - You should really focus on reading your logs, because they
really do
> >> > indicate that the userdb_mail_crypt_private_password is not
exprted in
> >> > anywhere, so clearly and obviously you are not able to access
the
> >> > mails.
> >> >
> >> > Maybe consider removing the master user authentication
completely?
> >> >
> >> > Aki

Serveria Support skrev den 2022-10-09 11:53:
>> Dovecot does it's best to hide passwords in logs, but unfortuntely
>> this isn't perfect.
doveconf -P | grep auth

maybe the issue is decrypt ?

On Sun, 9 Oct 2022, Serveria Support wrote:
> So this means passwords cannot be masked/hidden in the logs? You realize
that
> it actually defeats the whole idea of encrypted storage? It's useless.
I can
> think of lots of scenarios: malicious system administrator reading users 
> mails and blackmailing them or selling their business secrets to
competitors,
> corrupt law enforcement in some countries getting rid of political or 
> business opponents by disclosing the contents of their mails and I can go
on
> and on and on... There is no such thing as semi-privacy. Privacy is either 
> there or it's not.
If your attack scenario includes somebody owning your server, nothing prevents 
them from compiling/installing a custom version of dovecot (or any other tool 
you may be using, like PAM, etc.) which dumps the passwords in clear text to a 
suitable file, pipe, or socket.

So good luck with that requirement..

Cheers,
Bernardo