Replies: 1 comment 1 reply
-
If this is a personal mail server, you shouldn't have to worry if you use a strong password (high entropy). A password manager is good for that, but something like I still have the mail encryption feature support on my TODO, it's scheduled after I wrap up the LDAP rework (which has been stuck on finding time to rewrite related docs). Hopefully this month I'll finally get that in 😓 The feature can be either:
With OAuth2, you login with your username and an access token. The access token is provided from your login session with the auth service handling your identity, then Dovecot will check with that auth service, giving it the access token received to confirm the token is still valid and that the email address associated to it is your login username (unless Dovecot was configured differently by the DMS admin). The access token is dynamic, so it can't be used to decrypt the mail. We don't control mail clients, AFAIK there is no way to prompt for a password from DMS/Dovecot, the information is expected at login implicitly. I am pretty sure that you can provide the password via other means though. So technically the auth service should be capable of returning other data beyond the email address. If it can include a user encryption key that could be used as input instead for decrypting, Dovecot just needs additional configuration to know about the field and add it into the PassDB for OAuth2. The actual key for decrypting your mail is protected via another layer of encryption IIRC. This is so that mail is only ever encrypted once to disk, and that if you change your password, we only need to know the original password (hashed) and the new one (hashed) to "change the lock" for the decryption key. You'll have a problem there with the OAuth2 process if that value is different from your hashed password. Due to that process above, you can support multiple secrets to encrypt the decryption key, but we only provide a CLI for password change to update it. With OAuth2, we could only query the active secret for that user, so if it differs from the password hash, and the auth service changed it, we don't have the original information to update/swap for the new secret...I'm terrible at explaining things 😆 Anyway, good news is it should be possible with some extra config. It just may not work well if the secret was to ever change (technically if it's not associated to a users password, and has enough entropy it shouldn't really need to change unless their was a compromise/leak). Just keep in mind that if the input required to decrypt the mail is lost with per-user keys, it's effectively impossible to recover from as the encryption strength would require enough energy to boil all the oceans in the world 🤯 |
Beta Was this translation helpful? Give feedback.
-
I've been using docker-mailserver for a while and already have single sign-on set up with Keycloak using OAuth2. I've completely disabled plaintext authentication because I was a little worried about the security (I've already seen a few bots try to brute force over SMTP), but now I've been thinking it would also be a good idea to try using mailcrypt to encrypt my emails on disk.
I know that you need the user password in order to decrypt emails stored on disk, and I also know that (at least in the official recommended steps to take on dovecot.org) that you're supposed to have a username/password database set up for mailcrypt to use. I don't want to break something in my mailserver from just messing around with this—has anybody tried using mailcrypt and OAuth2 at the same time? What should I do?
I've already looked through this thread, which is where I got some clarification on the database requirement, but it still seems like after all the work they did in that thread that a password is required.
The optimal flow in my eyes is that I can authenticate using OAuth2, but then I'm given just a password box so that I can type in a password to decrypt my mail. If anyone here is experienced with Vaultwarden, I think it should work like that, where OAuth2 doesn't get you in to the encrypted files, it just works in place of the "username/email" box.
For the client that I usually use to connect to the mailserver, I use Roundcube.
Just as a note, I don't need any emails that I already have to be encrypted or anything like that—I don't have any real major security or privacy concerns that mean that I need to do this, either—I just think that if I can, then I should, and I like learning about these things.
Beta Was this translation helpful? Give feedback.
All reactions