Timo Sirainen wrote:
1 LOGIN tmetro@example.com password 1 NO Login failed: Unsupported authentication mechanism
The error message is fine for AUTHENTICATE command I think, but for LOGIN it could be something like: "Plaintext authentication mechanism is disabled"
Yes, that would help clarify.
That got me wondering whether there were two different areas where authentication terms apply - one being the password exchange in the IMAP protocol, and the other being how the password is stored on the server - yet the discussion of the two seems to be mixed together in the documentation.
Where? I don't see any obvious mixes, except that DIGEST-MD5...
http://dovecot.org/doc/auth.txt says:
Authentication is split into three parts: authentication mechanism, password database and user database.
Which is good, except it never defines what "authentication mechanism" really means, and how it is distinct from how the password is stored.
Password database is quite self explanatory, but it wouldn't hurt to explain the purpose of the user database here.
The information in auth.txt is of course technically correct, but the listing of mechanisms at the top of the file looks enough like the list of schemes under "Generating passwords" to cause confusion.
...DIGEST-MD5 is both an authentication mechanism name and password scheme name (because they're supposed to be used together).
That's enough to start raising confusion. There are PLAIN-MD5 and MD5 schemes that look similar to PLAIN and CRAM-MD5 mechanisms. When you're looking at something as a new user, you never know if the differences are significant or just inconsistencies.
DIGEST-MD5 scheme isn't very useful unless you're using DIGEST-MD5 authentication.
A pretty important point that isn't made in auth.txt.
Quoting from auth.txt again:
Most password databases support only plaintext authentication. passwd-file and LDAP exceptions since they support multiple password schemes.
The reasoning behind this should be explained. (Though that would be more obvious once "authentication mechanism" is well defined.) Also the wording is confusing as it is, and also out of date because it doesn't mention pgsql and mysql.
The point you want to make is that if the client authenticates using plain text in the IMAP protocol, then Dovecot can encrypt the password to match a variety of encryption schemes used in password databases.
If the client authenticates using a mechanism like DIGEST-MD5, which is a one-way hashing algorithm, Dovecot can't "translate" it to some other scheme, so the password databases must use a password encryption scheme that matches the IMAP protocol authentication mechanism.
How about:
Space separated list of wanted authentication mechanisms:
plain digest-md5 anonymous
All IMAP/POP3 clients support plain-authentication. Digest-MD5 is more
secure, but it's not widely supported by clients. Note that by default
plaintext authentication is disabled unless SSL is used - see
disable_plaintext_auth setting.
auth_mechanisms = plain
Here too, I think it would be useful to define "authentication mechanisms", but you should probably first provide a better definition for "Authentication processes." Though the term "process" makes me think that we're talking about an executable. But I guess it is defining the behavior of a child process - right?
Perhaps:
Authentication processes
An Authentication process is a child process used by Dovecot that
handles the authentication steps. The steps cover an authentication
mechanism (auth_mechanisms, how the client authenticates in the IMAP
protocol), which password database should be queried (auth_passdb),
and which user database should be queried (auth_userdb, to obtain
UID, GID, and location of the user's mailbox/home directory).
You can have multiple processes, though a typical configuration will
have only one. Each time "auth = xx" is seen, a new process
definition is started. The point of multiple processes is to be able
to set stricter permissions. (See auth_user below.)
Just remember that only one Authentication process is asked for the
password, so you can't have different passwords accessible through
different process definitions (unless they have different
auth_mechanisms, and you're ok with having different password for
each mechanisms).
(What is the order in which Authentication processes are chosen, if say, you have multiple defined for the 'plain' auth_mechanisms? Or is that considered a configuration error?
The above paragraph might be describing an obscure enough condition that it would be better moved to auth.txt. If anything, the point you might want to get across is that each auth mechanism should uniquely map to a single password database.)
And...
Specifies how the client authenticates in the IMAP protocol.
Space separated list of permitted authentication mechanisms:
anonymous plain digest-md5 cram-md5
anonymous - No authentication required.
plain - The password is sent as plain text. All IMAP/POP3 clients
support this, and the password can be encrypted by Dovecot to match
any of the encryption schemes used in password databases.
digest-md5 and cram-md5 - both encrypt the password so it is more
secure in transit, but are not well supported by clients, and
require that the password database use a matching encryption
scheme.
See auth.txt for more details.
If you are using SSL there is less benefit to digest-md5 and
cram-md5 as the communication is already encrypted. Note that by
default plain text authentication is disabled unless SSL is used -
see disable_plaintext_auth setting.
auth_mechanisms = plain
(I thought by default disable_plaintext_auth=no. Has that changed?
My assertion, "the password can be encrypted by Dovecot to match any of the encryption schemes used in password databases," may not be accurate. Your comments seem to imply that Dovecot won't translate a plain password to a digest-md5 storage scheme (perhaps also cram-md5), though it seems this should be possible.)
-Tom