Definitive test would be to use an SQL statement to manually change the
cleartext password in the database, and then see if Dovecot allows
authentication against that new password.  If authentication succeeds,
then the only plausible explanation is that Dovecot is directly
accessing the cleartext passwords.

I have little SQL knowledge and even less experience, so I'm not brave
enough to try this on my system. :)

-Andy


On 10/2/2018 8:47 PM, Eric Broch wrote:
> And when debugging authentication with Dovecot, I get...
> 
> CLEARTEXT(password entered in webmail) != 'password in the database'
> 
> From dovecot.log the actual output:
> 
> Oct 02 22:05:45 auth-worker(19953): Debug:
> vpopmail(someu...@domain.tld,127.0.0.1,<dVsPJ0t3GIl/AAAB>):
> CLEARTEXT(xxxxxxxxxxxxxxxxx) != 'xxxxxxxxxxxxxxxx'
> Oct 02 22:05:47 auth: Debug: client passdb out: FAIL    1
> user=someu...@domain.tld
> 
> 
> 
> 
> On 10/2/2018 10:25 PM, Eric Broch wrote:
>> So, I think Dovecot MAY be authenticating against the plain text
>> password. I can't be sure until I look at the code or ask on the
>> Dovecot mailing list.
>>
>>
>> On 10/2/2018 10:22 PM, Eric Broch wrote:
>>> Okay,
>>>
>>> 17 character password works with Submission port. Not with IMAP which
>>> is authenticated through Dovecot.
>>>
>>> Eric
>>>
>>>
>>> On 10/2/2018 9:21 PM, Andrew Swartz wrote:
>>>> Eric,
>>>>
>>>> Regarding the hash: difficult to answer because of the atypical storage
>>>> method (in the database).  It looks like two items (username and
>>>> password???), each stored in an atypical base64 (using "." instead of
>>>> "+" for the 64th character) and each prefixed with a "$" and then
>>>> concatenated. Unfortunately, this makes it difficult to know what the
>>>> hash "should" be.  Each of these could also be salted. Browsing the
>>>> vpopmail source code would likely clear this up. Unsure when I'll have
>>>> time for that.
>>>>
>>>> I was testing passwords using Squirrelmail, which goes through IMAP,
>>>> which means that Dovecot does the authentication (I believe). It is
>>>> possible that dovecot (Centos7) is authenticating differently than did
>>>> courier-IMAP (Centos5).  There are two places in
>>>> /etc/dovecot/toaster.conf which specify "driver = vpopmail". I have no
>>>> idea what the detailed implications of that setting are.
>>>>
>>>> It would be interesting to see if the 16 or 17 character passwords work
>>>> for qmail-smtp.  Could try to telnet to port 25 and see if qmail
>>>> accepts
>>>> the 16 or 17 character password for relay.  If qmail takes the 17
>>>> character password and not the 16, it would indicate a different
>>>> authentication method than via IMAP.  This would mean that the database
>>>> is not the problem.
>>>>
>>>> Unfortunately, and not somewhere that allows me to try this right now.
>>>>
>>>> -Andy
>>>>
>>>>
>>>>
>>>> On 10/2/2018 6:47 PM, Eric Broch wrote:
>>>>> Okay,
>>>>>
>>>>> Set user's password to 17 x's, eg: xxxxxxxxxxxxxxxxx
>>>>>
>>>>> I could not log in with 17x password but I could with 16x password.
>>>>>
>>>>> Not sure what this means, I'm open to enlightenment. Could it be
>>>>> the hash?
>>>>>
>>>>>
>>>>>
>>>>> On 10/2/2018 8:41 PM, Eric Broch wrote:
>>>>>> Will do.
>>>>>>
>>>>>>
>>>>>> On 10/2/2018 8:40 PM, Andrew Swartz wrote:
>>>>>>> Eric,
>>>>>>>
>>>>>>> Before I do that, can you see if you can replicate the problem: On
>>>>>>> Centos7, create an account with a long password and see if you
>>>>>>> can then
>>>>>>> log in with the long password.  If that fails, then try with the
>>>>>>> first
>>>>>>> 16 characters of that password.
>>>>>>>
>>>>>>> -Andy
>>>>>>>
>>>>>>>
>>>>>>> On 10/2/2018 6:28 PM, Eric Broch wrote:
>>>>>>>> Andrew,
>>>>>>>>
>>>>>>>>
>>>>>>>> On 10/2/2018 7:34 PM, Andrew Swartz wrote:
>>>>>>>>> 1.  vpopmail (or something else) is NOW authenticating against the
>>>>>>>>> cleartext password instead of the hash.
>>>>>>>> I don't think so, or I hope not. I've done nothing except compile
>>>>>>>> vpopmail on CentOS 7 back in 2015 no patches.
>>>>>>>> The only change, if I remember correctly, is MariaDB requirements
>>>>>>>> rather
>>>>>>>> the MySQL.
>>>>>>>>> 2.  vpopmail (or something else) is NOW truncating the password
>>>>>>>>> at 16
>>>>>>>>> characters when it is set (i.e. hashed), but not during subsequent
>>>>>>>>> authentication.
>>>>>>>> I hope it's something else.
>>>>>>>>> 3.  mysql was storing something in the cleartext password field
>>>>>>>>> which it
>>>>>>>>> did not export.  This seems unlikely, as I can see 16 characters
>>>>>>>>> and the
>>>>>>>>> field type is "char(16)".  I went through the database export
>>>>>>>>> file,
>>>>>>>>> and
>>>>>>>>> its contents appear the same as those of the running mysql
>>>>>>>>> database on
>>>>>>>>> Centos5, which is the same as the running mariadb database on
>>>>>>>>> Centos7 (I
>>>>>>>>> view the contents with WebMin).  Therefore it appears that the
>>>>>>>>> backup/restore worked properly.
>>>>>>>> Maybe something worth my time: Bring up two qmail (w/vpopmail)
>>>>>>>> VM's on
>>>>>>>> COS5 and COS7.
>>>>>>>> Next, Create a domain and user entry on COS5 with >16 length
>>>>>>>> password.
>>>>>>>> Dump the vpopmail db on COS5 (vpopmail-cos5db), and import it on
>>>>>>>> COS7.
>>>>>>>> Dump the vpopmail db on COS7 (vpopmail-cos7db), and compare
>>>>>>>> (diff) the
>>>>>>>> two dumps.
>>>>>>>> If they're the same it could possibly be an issue with the vpopmail
>>>>>>>> program.
>>>>>>>>
>>>>>>>> If you were up to it, you could also create a database called
>>>>>>>> vpopmail1
>>>>>>>> on your COS7 machine,
>>>>>>>> and import the COS5 vpopmail db into it (that way it doesn't
>>>>>>>> mess with
>>>>>>>> your regular vpopmail db), and
>>>>>>>> dump it and compare the two (COS5/COS7) dumps.
>>>>>>>>> Does anyone know the details of how vpopmail interacts with the
>>>>>>>>> database
>>>>>>>>> server?  Or if any authentication is done by some means other than
>>>>>>>>> through vpopmail?
>>>>>>>> Interaction with db by vpopmail is done at compile time.
>>>>>>>>
>>>
>>
> 

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to