Headsup on feature removal - password

[Vesselin Kolev]

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