Hi,
Yeah, I just realized myself that what I did there was probably not the
smartest thing to do, as I indeed figured dovecot would probably just use that
as a plain text string. ;-) I've now opted to do the following (I'm using
PostgreSQL BTW):
password_query = SELECT \
email as user, password, \
encode(digest('%w', 'sha256'), 'hex') AS userdb_mail_crypt_private_password \
FROM virtual_users WHERE email='%u';
Please advice if you think that this is more sensible.
Also, could you give an overview of in which logs and/or other locations these
passwords might show up? I'd like to clean up after myself.
Thanks in advance.
------- Original Message -------
On Saturday, March 4th, 2023 at 15:38, Aki Tuomi <aki.tu...@open-xchange.com>
wrote:
> Hi,
>
> just to mention this. If you use the stored password hash, it equals to using
> a plain text string. Depending on your threat model it might or not be an
> issue that admins have access to the password used to encrypt mails.
>
> Aki
>
>> On 04/03/2023 16:12 EET Jeremy <mailinglist-subscripti...@protonmail.com>
>> wrote:
>>
>> Hi again,
>>
>> I was able to solve both questions. I was overthinking things.
>>
>> A solution to the first question about mail_attribute_dict was simply to use
>> other available variables to point to the virtual user's maildir paths. Like
>> so: /var/mail/%d/%u/dovecot-attributes
>>
>> As for the second question:
>> When I asked it, I was uncertain if dovecot would be able to cope with a
>> hashed password for userdb_mail_crypt_private_password. I somehow believed
>> dovecot required a plain text password there, as per the '%w' in the example
>> password_query. Turns out this was not the case. Simply providing the
>> already hashed password of the password field did the trick. So:
>>
>> password_query = SELECT \
>> email as user, password, \
>> password AS userdb_mail_crypt_private_password \
>> FROM virtual_users WHERE email='%u';
>>
>> Hope this is of help to others if they stumble upon this question.
>>
>> ------- Original Message -------
>> On Thursday, February 23rd, 2023 at 08:53, Jeremy
>> <mailinglist-subscripti...@protonmail.com> wrote:
>>
>>> Hi again,
>>>
>>> I am using dovecot 2.3.16, along with postfix and a PostgreSQL database for
>>> managing virtual accounts.
>>>
>>> After an initial topic from me about encrypting already existent mail, I
>>> could now use some pointers on how to set up the mail-crypt plugin for pure
>>> virtual accounts (i.e. that have no matching system users and/or home
>>> directories. I hope somebody can clarify a few things that are not entirely
>>> clear to me yet.
>>>
>>> After doing my own research, I believe the following should be possible:
>>>
>>> I'd like to use the password of virtual email accounts to let dovecot
>>> encrypt/decrypt the keys needed to encrypt/decrypt the mail in the relevant
>>> folders.
>>>
>>> As per the documentation @
>>> https://doc.dovecot.org/configuration_manual/mail_crypt_plugin/ I believe
>>> this would be all the configuration I need:
>>>
>>> # Config
>>> mail_attribute_dict = file:%h/Maildir/dovecot-attributes
>>> mail_plugins = $mail_plugins mail_crypt
>>>
>>> plugin {
>>> mail_crypt_curve = secp521r1 # or some other preferred curve
>>> mail_crypt_save_version = 2
>>> mail_crypt_require_encrypted_user_key = yes # necessary for encrypting keys
>>> with user password
>>> }
>>>
>>> # File: /etc/dovecot/dovecot-sql.conf.ext
>>> password_query = SELECT \
>>> email as user, password, \
>>> '%w' AS userdb_mail_crypt_private_password \
>>> FROM virtual_users WHERE email='%u';
>>>
>>> My first question is:
>>> Is it possible to configure mail_attribute_dict in such a way as to not use
>>> home directories. Since I only use virtual accounts, without those accounts
>>> having home directories, can I somehow tell dovecot to save the attributes
>>> into the PostsreSQL database, for instance? If not, can you suggest another
>>> approach, without having to create home directories for virtual users?
>>>
>>> My second question is:
>>> The documentation warns about not using password directly in the above SQL
>>> query:
>>>
>>>> Choosing encryption key
>>>
>>>> DO NOT use password directly. It can contain % which is interpreted as >
>>>> variable expansion and can cause errors.
>>>
>>> Does this refer to not accidentally substituting '%w' with password? In
>>> other words, if I leave the above query as is, should I be good, even if
>>> plain text passwords of users potentially have % signs in them? Or would I
>>> need to take further measurements? (The passwords in my database are
>>> already hashed, by the way).
>>>
>>> I hope somebody can offer some guidance on this. Thanks.
>
> ---
> Aki Tuomi
