Solved Dovecot password missmatch after lastest update 01/2020

W

wisdown

After enable all log and debug, have found where the problem occour on auth-worker which is getting plain password and not hashing it:

Code: 
... SHA512-CRYPT(plainpasswordhere) != 'HASH value from mysql'


Then occours password missmatch error.

Someone have same issue?

PS.: Happen on last update of openssl, where openssl111 was dropped for openssl (already rebuild everything).
 
Do you have a parameter in your stored MCF string or is a new/different parameter being applied with new default settings, such as $6$rounds=25600$blablablablabla
 
msplsh said:
Do you have a parameter in your stored MCF string or is a new/different parameter being applied with new default settings, such as $6$rounds=25600$blablablablabla
Click to expand...


This is the start from one password on Database and second part of logs:

Code: 
So using the revious log would be:

[CODE]... SHA512-CRYPT(plainpasswordhere) != '$6$54dfc48285050049$IscEu2blablabla'

Have update again passwords for test using on MariaDB:

Code: 
ENCRYPT('plainpasswordhere', CONCAT('$6$', SUBSTRING(SHA(RAND()), -16)))
 
I don't understand what you've typed, but I do see that '$6$54dfc48285050049$IscEu2blablabla' appears to be a salted sha512crypt MCF hash with "54dfc48285050049" being the salt. If you're not passing the correct salt for each password into SHA512-CRYPT, that will cause an issue.

Your ENCRYPT() example is... bizzare.
  • It's unsalted
  • It shouldn't work, as SHA() doesn't look like a MariaDB function, only SHA1() and SHA2() are. Without the second parameter to SHA2() being 512, this will default to 256.
  • I don't understand the point of SUBSTRING() chopping off important parts of the hash... OH WAIT, the salt is 16 characters long. Wow, yes, that is very wrong.
 
The full Update for an user using phpMyAdmin is:

Code: 
UPDATE `virtual_users` SET `password`=ENCRYPT('plainpassword64charshere', CONCAT('$6$', SUBSTRING(SHA(RAND()), -16))) WHERE id = XXXX;

Was working before update my Mailserver, I will wait finish the rebuild the database server to confirm an hypothesis:

"Maybe because openssl has changed on mail server, I need do same update for get same hashes on database server (where log info is)"
 
msplsh said:
I don't understand the point of SUBSTRING() chopping off important parts of the hash... OH WAIT, the salt is 16 characters long. Wow, yes, that is very wrong
Click to expand...

How do you do the insert on this situation (SHA512 min pass 24 chars max 64 chars)?

After update the Database server, everything back to work again, andthe hash have changed also.

In another words:

Everytime change openssl, need update the database passwords hash also, and openssl on all servers too.
 
You haven't posted relevant Dovecot configuration lines such as
  • default_pass_scheme
  • password_query
  • disable_plaintext_auth
  • auth_mechanisms
I finally understand what you're doing here with the SHA() function, which is attempting to get a random salt. Since ENCRYPT() just passes stuff to the system level crypt(3) function, and that is handled by openssl, this would explain why updating openssl might cause a problem.

I don't like how the salt is being selected because it relies on too many assumptions. It may be invalid, which would explain why openssl would not like it, so if you could, post the SQL output of running

Code: 
SELECT CONCAT('$6$', SUBSTRING(SHA(RAND()), -16)))

That along with the bulleted configuration lines might help debugging.

I like some of the other suggestions in this Stack Overflow thread about how to generate fixed-length random strings.

I'm also going to stick this portion of the dovecot manual for passwords here for reference later.
 
Thanks for the link, I still looking for how to use only MySQL to get ARGON2I/ARGON2ID Hashes, then instead of SHA512 I would use it.

The details asked are:

  • default_pass_scheme
SHA512-CRYPT

  • password_query
SELECT email as user, password, maildir as userdb_home, uid as userdb_uid, gid as userdb_gid, CONCAT('*:storage=', quota, 'B') AS userdb_quota_rule, CONCAT(maildir,'./sieve') as userdb_sieve FROM virtual_users WHERE email = '%u' AND active = '1'

  • disable_plaintext_auth
disable_plaintext_auth = yes

  • auth_mechanisms
auth_mechanisms = plain login

By the way I am using opportunist encryption, DANE, and other security meassures.

Have shared the issue to save time of people in same situation.

PS.: If you have examples for each method of encryption using only MySQL, would include that in the manual. I am pretty sure this would help a lot of people.
 
Is SSL turned on? You can't use SHA512-CRYPT with it disable_plaintext_auth=yes if ssl=no.

Did you manage to get the output of

Code: 
SELECT CONCAT('$6$', SUBSTRING(SHA(RAND()), -16)))
 
Thank you for the reply msplsh

Got it solved, problem was on openssl.

Since I store the hashed value on MariaDB, both openssl (mail server and database server - two distinvt Virtual machines) need be same to hash match.

Problem started after update the openssl on mail server.
Then mail server was making an different hashe.

After update openssl on Database server and renew the password (new version make new hash value) everything works without any change.


I still in doubt if I keep the hash on database like security practices recomends, or just plain, since every future update of openssl in similar situation would redo same problem (missmatch hashs).
 
I'm glad you got it solved, but I'm curious as to why the hash was different between the OpenSSL versions. Maybe the default rounds changed.
 
You must log in or register to reply here.
Back
Top