About authentication methods: Update

2021-01-27

A month ago, I questioned the value of newer authentication methods, in particular SCRAM-SHA-*, compared to simple PLAIN authentication over TLS, and concluded with "I really hope I'm wrong". Well, the good news is: I was wrong!

Here are the main points that convinced me:

Storing hashed and salted passwords is good.
Previously I believed that everyone should simply use unique strong passwords so that just hashing them is a sufficient countermeasure against password theft. But that is a naive view (and it was arrogantly phrased). It will never happen. So the attractiveness of authentication databases for the bad guys must be reduced as much as possible. Salting helps.
Having guarantees about the server identity that are independent of the TLS trust model is good.
With SCRAM-SHA-*, the server must prove to the user that it is in possession of the (hashed and salted) password. This makes it far more difficult for an attacker to impersonate a server, even if he manages to get the user to accept a forged TLS certificate. And this is a good thing, given the questionable trust model of TLS.

These two points are enough to actually reverse my point of view completely: ideally every service should offer only SCRAM-SHA-* authentication and drop support for PLAIN and others, to enforce that these benefits become ubiquitous.

My thanks to everyone who sent me comments and helped to convince me!

Also, to clarify: with GNU SASL, msmtp and mpop support SCRAM-SHA-1 and in the next version will also support SCRAM-SHA-256.

Update 2021-01-30: This does not mean that SCRAM-SHA-* is without flaws. See this comment by Simon Josefsson, who is an expert in these matters.

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.