Setting up the mail-crypt plugin with virtual accounts that have no home directories
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.
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-subscriptions@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.
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.tuomi@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-subscriptions@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-subscriptions@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
Hi,
Thanks for the notice! But yes, I was aware of this. For future reference though, would you mind telling me how I would go about doing this? I take it I'd first have to re-encrypt the user keys, before changing the account password. So before changing the password for a user in my PostgreSQL database, I would do the following:
doveadm mailbox cryptokey password -u 'user@example.com' -o <hex-encoded sha256-hashed old password> -n <hex-encoded sha256-hashed new password>
since I am using encode(digest('%w', 'sha256'), 'hex') in the PostgreSQL password_query. Can you confirm that this is the correct way to change the user keys' password? Thanks. ------- Original Message ------- On Saturday, March 4th, 2023 at 16:41, Aki Tuomi aki.tuomi@open-xchange.com wrote:
Dovecot tries to hide passwords in logs so you're probably safe.
Remember that there is no automatic password change for mail crypt. If user's password is changed, it will require corresponding update for user's master key.
Aki
On 04/03/2023 17:07 EET Jeremy mailinglist-subscriptions@protonmail.com wrote:
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.tuomi@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-subscriptions@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-subscriptions@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
Aki Tuomi
Thanks for the reassurance and the other assistance you have provided! Everything seems to work a treat. ------- Original Message ------- On Sunday, March 5th, 2023 at 18:00, Aki Tuomi aki.tuomi@open-xchange.com wrote:
Order does not matter much as long as you do it about same time. But otherwise, yes.
Aki
On 05/03/2023 18:43 EET Jeremy mailinglist-subscriptions@protonmail.com wrote:
Hi,
Thanks for the notice! But yes, I was aware of this. For future reference though, would you mind telling me how I would go about doing this? I take it I'd first have to re-encrypt the user keys, before changing the account password. So before changing the password for a user in my PostgreSQL database, I would do the following:
doveadm mailbox cryptokey password -u 'user@example.com' -o <hex-encoded sha256-hashed old password> -n <hex-encoded sha256-hashed new password>
since I am using encode(digest('%w', 'sha256'), 'hex') in the PostgreSQL password_query.
Can you confirm that this is the correct way to change the user keys' password? Thanks. ------- Original Message ------- On Saturday, March 4th, 2023 at 16:41, Aki Tuomi aki.tuomi@open-xchange.com wrote:
Dovecot tries to hide passwords in logs so you're probably safe.
Remember that there is no automatic password change for mail crypt. If user's password is changed, it will require corresponding update for user's master key.
Aki
On 04/03/2023 17:07 EET Jeremy mailinglist-subscriptions@protonmail.com wrote:
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.tuomi@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-subscriptions@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-subscriptions@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
Aki Tuomi
Aki Tuomi
participants (2)
-
Aki Tuomi
-
Jeremy