Hello Rupert,

Note the following - using X.509 certificates is an excellent idea for preventing password guessing, but you need to realize one very important thing before switching to X.509 certificate authentication. In TLSv<=1.2 the TLS handshake leaks the client X.509 certificate. Simply start capturing the traffic with tcpdump (increase the verbosity), then initiate a new TLS session from the IMAP client, and you will see the X.500 subject of your client's certificate captured. Yes, the certificate itself is not a piece of critical information that someone can use to guess the client's RSA or EC private key, but nevertheless everyone eavesdropping the traffic will know your clients identity and may count their activity, especially if the certificate subject contains e-mail address (you can hardly avoid that if the IMAP server hosts virtual e-mail domains).

One possible way to deal with that leak is to initiate the TLS session between the client and the server without prompting for a client's certificate, and only after the session gets established to re-negotiate that same session, but this time by requesting the client's X.509 certificate. Then the client's certificate cannot leak (it is exchanging inside the already established TLS tunnel). While it is possible to implement the re-negotiation for web-applications, I haven't seen so far anything similar implemented for IMAP+TLS or SMTP+TLS servers. I am not aware how does TLSv1.3 deals with that matter. I have seen some discussions, like this one:

https://bugs.chromium.org/p/chromium/issues/detail?id=911653

but they are not focused on IMAP.

I know it might sound really strange that tunneling the used name and password keeps the privacy of the users better that X.509 certificate, but we need to face the reality.

Anyway, if you and your clients can live with such а leak, you can implement X.509 certificate authentication.

Best,

Veselin

On 3/17/20 3:06 PM, Rupert Gallagher wrote:

...

Password schemes: HMAC-MD5, RPA, SKEY, PLAIN-MD4, LANMAN, NTLM, SMD5

The web is flooded with plain text passwords and hashed passwords harvested from hacked servers.

Dovecot stores passwords with the same scheme used for client authentication.

Therefore, we use crammd5/hmac-md5. It does not look like much, but is better than plaintext.

As md5 is about to go, and I have no intention to store passwords in plaintext, I need to split the scheme used to store passwords from the scheme used for authentication, and migrate storage from md5 to bcrypt.

Since this is not possible, I think I will drop passwords entirely and use certificates.