About authentication methods

2020-12-28

This article asks why there are so many authentication methods when the simplest one works just fine.

There are several methods for password-based authentication with SMTP, POP3, IMAP and other protocols. The simplest one is PLAIN. It just sends user name and password, and that's it. The server side only needs to store a hash of the password, not the password itself, so it cannot be stolen from the server. The client side can store the password encrypted, so it cannot be stolen from the client either (in msmtp and mpop: use a keyring or use gpg with passwordeval). The transmission of the password is inside a TLS-secured session, so the client knows it is really talking to the right service and not to an attacker, and eavesdropping is prevented.

So, all problems are solved, right? But why then are there so many authentication methods? I have not found a convincing answer to this question yet. In the following, I will argue that even the relatively new SCRAM-SHA-256 method does not provide any practical benefit over PLAIN and is far more complex than it should be. If I am wrong, please send me a mail and correct me. I promise I will update this article with all the convincing arguments I receive.

My premise is that everyone is using TLS for every SMTP, POP3 or IMAP session nowadays, since there is no such thing as a trustworthy network.
So what benefits does SCRAM-SHA-256 promise? According to RFC 5802:

• There are some significant security concerns with the transmission of clear-text passwords over a TLS-protected channel.
  Are there? The RFC does not list any. Please specify.
• The authentication information stored in the authentication database is not sufficient by itself to impersonate the client.
  This is true also PLAIN when the server stores just hashes.
  The information is salted to prevent a pre-stored dictionary attack if the database is stolen.
  Dictionary attacks do not help with good passwords. And if the user is too stupid to use a password manager for good unique passwords, then inventing a more complicated authentication method will not help you: your user will still write the password on a post-it note, stick it on a monitor, and then post a photo of his desk on social media. He will also without hesitation run any software from any source on his computer and not care about security updates or privacy settings. In other words: the user must be educated, you cannot solve this problem with technical means.
• The server does not gain the ability to impersonate the client to other servers.
  If you cannot trust your mail server, then it is game over anyway, so this is not a relevant concern.
• Mutual authentication is supported.
  Why would the client want the server to authenticate itself? It is already using TLS and has verified that it is talking to the right server.
• SCRAM is capable of transporting authorization identities.
  For what purpose? This is not needed for password-based authentication.
• Support for channel binding.
  This has absolutely no benefit when always using TLS, as far as I can see.
• Support for Unicode user names and passwords.
  PLAIN supports that too, and in a much simpler way: it sees both user name and password simply as byte sequences. Of course both should be valid UTF-8, but that does not need to concern the method; this is handled simply on the client side. No need for stringprep and other Unicode-interpreting mess like in SCRAM-SHA-256!

Update 2021-01-27: Here's the update I promised. The good news: I was wrong.

Update 2021-06-15: Simon Josefsson wrote an article about authentication mechanisms. It highlights problems with SCRAM, but also points out that SCRAM addresses some shortcomings of simpler mechanisms such as PLAIN.