Thinking through why you shouldn't use plaintext passwords in authentication, even inside TLS

January 10, 2021

I recently read an article (this one, via) that advocated for just using plaintext passwords inside TLS for things like IMAP and (authenticated) SMTP. My gut reaction was that this was a terrible idea in general, but I couldn't immediately come up with a solid reason why and why other alternatives are better for authentication. So here's an attempt.

There are (at least) two problems with passwords in general. The first problem is that people reuse passwords from one place to another, so knowing someone's password on site A often gives an attacker a big lead on breaking into their accounts elsewhere (or for other services on the site, if it has multiple ones). The second problem is that if you can obtain someone's password from a site through read-only access, you can usually leverage this to be able to log in as them and thus change anything they have access to (or even see things you couldn't before).

The consequence of this is that sending a password in plaintext over an encrypted connection has about the worst risk profile for various plausible means of authentication. This is because both ends will see the password and the server side has to directly know it in some form (encrypted and salted, hopefully). Our history is full of accidents where the client, the server, or both wind up doing things like logging the passwords by accident (for example, as part of logging the full conversation for debugging) or exposing it temporarily in some way, and generally the authentication information the server has to store can be directly brute forced to determine those passwords, which can turn a small information disclosure into a password breach.

So what are your options? In descending order of how ideal they are, I can think of three:

  • Have someone else do the user authentication for you, and only validate their answers through solidly secure means like public key cryptography. If you can get this right, you outsource all of the hassles of dealing with authentication in the real world to someone else, which is often a major win for everyone.

    (On the other hand, this gives third parties some control over your users, so you may want to have a backup plan.)

  • Use keypairs as SSH does. This requires the user (or their software) to hold their key and hopefully encrypt it locally, but the great advantage is that the server doesn't hold anything that can be used to recover the 'password' and a reusable challenge never goes across the network, so getting a copy of the authentication conversation does an attacker no good.

    (If an attacker can use a public key to recover the secret key, everyone has some bad problems.)

  • Use some sort of challenge-response system that doesn't expose the password in plaintext or provide a reusable challenge, and that allows the server side to store the password in a form that can't be readily attacked with things like off the shelf rainbow tables. You're still vulnerable to a dedicated attacker who reads out the server's stored authentication information and then builds a custom setup to brute force it, but at least you don't fall easily.

    (OPAQUE may be what you'd want for this, assuming you were willing to implement an IETF draft. But I haven't looked at it in detail.)

As far as the practical answers for IMAP, authenticated SMTP, and so on go, I have no idea. For various reasons I haven't looked at alternative authentication methods that IMAP supports, and as far as websites go to do anything other than plaintext passwords that get passed to you over HTTPS, you'd have to implement some security sensitive custom stuff (which has been done by people who had a big enough problem).

Comments on this page:

By Andrew at 2021-01-11 00:31:23:

Of course, using plaintext passwords over TLS is exactly what 99% of websites do when they log you in (maybe in concert with 2FA, but that doesn't do anything to protect the password itself; it just hopefully limits the impact of having the password exposed).

By at 2021-01-11 01:49:18:

Oauth2 support was added to IMAP and SMTP. Main use case is Gmail.

But it supposes change in MUA. For old MUA, Gmail proposes App token, shown only once and revocable, as an alternative to use your (master) password.

In entreprises with Dovecot for zxample, it supposes to change the password hases sources. Not many tutorials demoes this scheme.

It’s such a pity that browsers never implemented practical, usable UX for HTTP Auth. It’s not entirely trivial to replace Basic with Digest auth, but is certainly quite practical – and support is essentially universal.

By Carl at 2021-01-11 22:46:10:

Never-mind, looks like Opaque covers it.

Written on 10 January 2021.
« What timestamps you get back along with Prometheus query results
How to make Bash fail badly on Ubuntu 16.04 by typo'ing a command name »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Jan 10 23:31:23 2021
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.