Authentication Problem
I am using SHA512-CRYPT scheme for passwords.
In my dovecot-sql.conf.ext, I have: default_pass_scheme = CRYPT
In 10-auth.conf, I have: auth_mechanisms = plain login digest-md5
M$ Outlook is refusing to authenticate, with error: Requested DIGEST-MD5 scheme, but we have only CRYPT
What an I missing??
I hate it that this has taken me round in circles :-)
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", grep ^[^#] :-)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Greetings On Thu, 2018-12-20 at 12:20 +0300, Odhiambo Washington wrote:
I am using SHA512-CRYPT scheme for passwords.
Yeah, there is a reason MD5 has been preferred to crypt for a very long time now, and the SHA512 isn't really any better.
In my dovecot-sql.conf.ext, I have: default_pass_scheme = CRYPT
In 10-auth.conf, I have: auth_mechanisms = plain login digest-md5 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ M$ Outlook is refusing to authenticate, with error: Requested DIGEST-MD5 scheme, but we have only CRYPT What an I missing??
You are not advertising 3 possible auth methods, I am assuming that plain will use the SQL extension. Unless you are going to setup a digest-md5 method I would remove it from the advertised methods as most clients will default to a digest method before selecting plain. Unless you control all the clients and can configure them to only use the plain method of auth (I would also be ensuring that you have TLS enforced in some way for this) then removal of the digest method is probably the best fix.
If the plain and/or login methods are failing check your sql config includes the passdb and userdb sections.
Nikolai Lusan <nikolai@lusan.id.au> -----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEVfd4GW6z4nsBxdLo4ZaDRV2VL6QFAlwbcFwACgkQ4ZaDRV2V L6T7IxAAjTQQfVngYU92oNfORwIeL6e9YZtvlLfo7V6d2PSgnzJ2Tdzyo2YA4AGy eApc9SoJra8IVzanv+s6yl0BJ/EXez/ugdZ5DEUzYTf7b1AVMnUYOKkCi4HeOzzx zttLF/Hd5ovwDRB1StNa5c1dsrN5lfwZy/cFwK+zOWwEZDBpYq3/y+IjsbWhCcW1 DVbrSshOUaFqZwRE7MFPHiwsyNxhiG8cciglgUKf5HdRaiwx5E1Xy9gASxaqrdqg GZpGbI7C8sAr92OvTvZlwThSOM6+aSgGIOATRS9S1Lh9x9H14ya1LtOE9XELSQPl gDI/HJKBym7D8BsnEPSZ+THRwWGQ6QyACZUN8q5OZMEyzS2AGECnSTYMgv4LjqBZ VbAaPZBAkhsuzVoWsd4xKiN9Qv3wQykDsSq6yahqiDzTXbsCA8HPMEQvw3hISttq WHdibiBP8cm2/8cz+8PM1+3Q08JMVRqmDLEIQ61gmg8UWhpCPbE3royBkHaj6wOR GeK4mG3cwYQu0JsoKDsFr7EvABErVRzrvkiMgnz/ivORkJVVtmxyYmG4t5VIT8FD Hq6A/c1VJ/GYLNHNWRFMRfiXIJB7fM6K0NWK1EN34QoHNbwb5qSL+c6t/BZ5BpzK c9zkU31FTqtSabUHzNPje6hzHMi5eZLhcH/MCZhD3Xv5+Gwxdug= =LQQ1 -----END PGP SIGNATURE-----
You've made this more difficult to understand, even :-)
So the answer is: Set the following in 10-auth.conf
- disable_plaintext_auth = no
- auth_mechanisms = plain
And yes, the encrypted passwords are stored in MySQL.
On Thu, 20 Dec 2018 at 13:36, Nikolai Lusan <nikolai@lusan.id.au> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Greetings On Thu, 2018-12-20 at 12:20 +0300, Odhiambo Washington wrote:
I am using SHA512-CRYPT scheme for passwords.
Yeah, there is a reason MD5 has been preferred to crypt for a very long time now, and the SHA512 isn't really any better.
In my dovecot-sql.conf.ext, I have: default_pass_scheme = CRYPT
In 10-auth.conf, I have: auth_mechanisms = plain login digest-md5 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ M$ Outlook is refusing to authenticate, with error: Requested DIGEST-MD5 scheme, but we have only CRYPT What an I missing??
You are not advertising 3 possible auth methods, I am assuming that plain will use the SQL extension. Unless you are going to setup a digest-md5 method I would remove it from the advertised methods as most clients will default to a digest method before selecting plain. Unless you control all the clients and can configure them to only use the plain method of auth (I would also be ensuring that you have TLS enforced in some way for this) then removal of the digest method is probably the best fix.
If the plain and/or login methods are failing check your sql config includes the passdb and userdb sections.
Nikolai Lusan <nikolai@lusan.id.au> -----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEVfd4GW6z4nsBxdLo4ZaDRV2VL6QFAlwbcFwACgkQ4ZaDRV2V L6T7IxAAjTQQfVngYU92oNfORwIeL6e9YZtvlLfo7V6d2PSgnzJ2Tdzyo2YA4AGy eApc9SoJra8IVzanv+s6yl0BJ/EXez/ugdZ5DEUzYTf7b1AVMnUYOKkCi4HeOzzx zttLF/Hd5ovwDRB1StNa5c1dsrN5lfwZy/cFwK+zOWwEZDBpYq3/y+IjsbWhCcW1 DVbrSshOUaFqZwRE7MFPHiwsyNxhiG8cciglgUKf5HdRaiwx5E1Xy9gASxaqrdqg GZpGbI7C8sAr92OvTvZlwThSOM6+aSgGIOATRS9S1Lh9x9H14ya1LtOE9XELSQPl gDI/HJKBym7D8BsnEPSZ+THRwWGQ6QyACZUN8q5OZMEyzS2AGECnSTYMgv4LjqBZ VbAaPZBAkhsuzVoWsd4xKiN9Qv3wQykDsSq6yahqiDzTXbsCA8HPMEQvw3hISttq WHdibiBP8cm2/8cz+8PM1+3Q08JMVRqmDLEIQ61gmg8UWhpCPbE3royBkHaj6wOR GeK4mG3cwYQu0JsoKDsFr7EvABErVRzrvkiMgnz/ivORkJVVtmxyYmG4t5VIT8FD Hq6A/c1VJ/GYLNHNWRFMRfiXIJB7fM6K0NWK1EN34QoHNbwb5qSL+c6t/BZ5BpzK c9zkU31FTqtSabUHzNPje6hzHMi5eZLhcH/MCZhD3Xv5+Gwxdug= =LQQ1 -----END PGP SIGNATURE-----
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", grep ^[^#] :-)
On Thu, 20 Dec 2018 at 15:23, Aki Tuomi <aki.tuomi@open-xchange.com> wrote:
On 20 December 2018 at 14:10 Odhiambo Washington < odhiambo@gmail.com> wrote:
You've made this more difficult to understand, even :-)
So the answer is: Set the following in 10-auth.conf
- disable_plaintext_auth = no
- auth_mechanisms = plain
And yes, the encrypted passwords are stored in MySQL.
You cannot use hashed passwords with digest-md5 mechanism.
Aki
So, for the record, whenever passwords are hashed, digest-md5 should be disabled/removed from auth_mechanisms.
My question though - for purposes of understanding - how does dovecot take the sent password from a client and match it against the hashed one stored in the DB (in my case)? What happens in between the process?
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", grep ^[^#] :-)
On Thu, 20 Dec 2018 at 15:54, Aki Tuomi <aki.tuomi@open-xchange.com> wrote:
On 20 December 2018 at 14:33 Odhiambo Washington < odhiambo@gmail.com> wrote:
On Thu, 20 Dec 2018 at 15:23, Aki Tuomi < aki.tuomi@open-xchange.com> wrote:
On 20 December 2018 at 14:10 Odhiambo Washington < odhiambo@gmail.com> wrote:
You've made this more difficult to understand, even :-)
So the answer is: Set the following in 10-auth.conf
- disable_plaintext_auth = no
- auth_mechanisms = plain
And yes, the encrypted passwords are stored in MySQL.
You cannot use hashed passwords with digest-md5 mechanism.
Aki
So, for the record, whenever passwords are hashed, digest-md5 should be disabled/removed from auth_mechanisms.
My question though - for purposes of understanding - how does dovecot take the sent password from a client and match it against the hashed one stored in the DB (in my case)? What happens in between the process?
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", grep ^[^#] :-)
Dovecot hashes the client sent password using the same salt and compares the result.
Aki Tuomi
At the expense of sounding stupid, could you please expound on the sequence? :)
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", grep ^[^#] :-)
On Thu, 20 Dec 2018, Odhiambo Washington wrote:
At the expense of sounding stupid, could you please expound on the sequence? :)
In a nutshell, during protocol handshake, the server gives the client a random string (nonce). Both the server and client performs a cryptographic hash of nonce+password, and the client tells the server the result of the hash, and the server compares the client's result with its own. If the results match, it proves the client has knowledge of the password.
The strength relies upon cryptographics hashes not being invertible. It's one way of protecting password from sniffing when you can't use SSL. However, there's many weaknesses: the password must be kept on the server in plaintext, offline brute forcing, etc.
Joseph Tam <jtam.home@gmail.com>
Nice to get to hear this. However, the password is not stored in clear text here. How then does it work?
On Fri, Dec 21, 2018, 00:58 Joseph Tam <jtam.home@gmail.com wrote:
On Thu, 20 Dec 2018, Odhiambo Washington wrote:
At the expense of sounding stupid, could you please expound on the sequence? :)
In a nutshell, during protocol handshake, the server gives the client a random string (nonce). Both the server and client performs a cryptographic hash of nonce+password, and the client tells the server the result of the hash, and the server compares the client's result with its own. If the results match, it proves the client has knowledge of the password.
The strength relies upon cryptographics hashes not being invertible. It's one way of protecting password from sniffing when you can't use SSL. However, there's many weaknesses: the password must be kept on the server in plaintext, offline brute forcing, etc.
Joseph Tam <jtam.home@gmail.com>
On Fri, 21 Dec 2018, Odhiambo Washington wrote:
Nice to get to hear this. However, the password is not stored in clear text here. How then does it work?
By using a password derivative (see 3.9 on the document I just referred to). Sorry, my memory this scheme is antiquated. However, as the document points out, it still need to be protected as if it was plaintext because knowledge of the contents will give access.
Joseph Tam <jtam.home@gmail.com>
On Fri, 21 Dec 2018 at 01:06, Joseph Tam <jtam.home@gmail.com> wrote:
On Thu, 20 Dec 2018, Joseph Tam wrote:
At the expense of sounding stupid, could you please expound on the sequence? :)
If you want the nitty details
(Starting at bottom of page 18) https://tools.ietf.org/html/rfc2831
Joseph Tam <jtam.home@gmail.com>
Thank you very very much! I have now kind of understood what goes own. Initially, the server "has knowledge" of the credentials of the user. It had to be in the RFC and those we always leave for 'others' to read :-)
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", grep ^[^#] :-)
participants (4)
-
Aki Tuomi
-
Joseph Tam
-
Nikolai Lusan
-
Odhiambo Washington