Dovecot mail-crypt webmail can't read encrypted messages

[Serveria Support]

> Passwords are hidden in logs, mostly. Debug logging unfortunately can
> leak some password information.

So why not just get rid of this attack vector? Who needs users' 
plaintext passwords in debug logs anyway? I can't think of a situation 
when this is necessary. But that's just me of course.

> Turn on auth_debug=yes and see, you'll see passwords being masked.

I have this value set to yes already and the passwords are not being 
masked. Perhaps you meant auth_debug_passwords = no?

> 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.

Will this work in doveadm commands? Or it has to be done in a PHP script 
feeding login data to dovecot (like webmail/frontend)? Will it prevent 
passwords from showing in the logs?


On 2022-10-09 14:02, Aki Tuomi wrote:
>> 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