You did send an email intended for the list (introduction: Hi Folks) but
you addressed it to me alone at 11:17 Mountain Standard Time or
Denver/America. If you check your Sent folder it would be a good
indication of the recipients.
On 10/3/2018 12:10 AM, Tony White wrote:
I sent an email to the list with a suggestion ages ago.
It has not arrived. Is there some protection against sql code?
On 03/10/18 15:28, Eric Broch wrote:
The solution might be to either patch dovecot with our own QMT patch
at compile time to avoid the clear text password altogether during
Or compile vpopmail clear text password field disabled,
Or, Another solution would be for users to clear all clear text
password fields from the vpopmail database before migration,
Or as Tony brought up changing the size of the clear password field
to 40 chars.
On 10/2/2018 11:21 PM, Eric Broch wrote:
Dovecot will authenticate against the clear text password if it is
Upon updating the clear text password (encrypted 17 characters) to
'null', I authenticated using Dovecot against the 17 character
Here's the command I used to set the clear text password to null:
mysql> update mydomain_tld set pw_clear_passwd='' where pw_name
Then Dovecot authenticated fine against the 17 character
password...now encrypted to 40 chars.
On 10/2/2018 11:09 PM, Andrew Swartz wrote:
On further review, your debug output looks pretty definitive for
directly accessing the database. Given that the hash cannot be
reversed, the only way to get the cleartext password is direct
This seems a pretty substantial problem, as it means that the hash and
cleartext will be discordant for passwords >16 characters. But nothing
stops users from choosing such passwords.
Or alternately, could be an interesting bug to capitalize on. It
creation of relay-only passwords. I could use this for accounts which
only send mail but which should never check it (like my UPS or system
monitoring scripts). From one perspective, this could be a security
advantage. But forcing real users to use small passwords is
much bigger disadvantage.
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:
CLEARTEXT(xxxxxxxxxxxxxxxxx) != 'xxxxxxxxxxxxxxxx'
Oct 02 22:05:47 auth: Debug: client passdb out: FAIL 1
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:
17 character password works with Submission port. Not with IMAP
is authenticated through Dovecot.
On 10/2/2018 9:21 PM, Andrew Swartz wrote:
Regarding the hash: difficult to answer because of the atypical
method (in the database). It looks like two items (username and
password???), each stored in an atypical base64 (using "."
"+" for the 64th character) and each prefixed with a "$" and then
concatenated. Unfortunately, this makes it difficult to know
hash "should" be. Each of these could also be salted. Browsing
vpopmail source code would likely clear this up. Unsure when
time for that.
I was testing passwords using Squirrelmail, which goes through
which means that Dovecot does the authentication (I believe).
possible that dovecot (Centos7) is authenticating differently
courier-IMAP (Centos5). There are two places in
/etc/dovecot/toaster.conf which specify "driver = vpopmail". I
idea what the detailed implications of that setting are.
It would be interesting to see if the 16 or 17 character
for qmail-smtp. Could try to telnet to port 25 and see if qmail
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
is not the problem.
Unfortunately, and not somewhere that allows me to try this
On 10/2/2018 6:47 PM, Eric Broch wrote:
Set user's password to 17 x's, eg: xxxxxxxxxxxxxxxxx
I could not log in with 17x password but I could with 16x
Not sure what this means, I'm open to enlightenment. Could it be
On 10/2/2018 8:41 PM, Eric Broch wrote:
On 10/2/2018 8:40 PM, Andrew Swartz wrote:
Before I do that, can you see if you can replicate the
Centos7, create an account with a long password and see if you
log in with the long password. If that fails, then try with
16 characters of that password.
On 10/2/2018 6:28 PM, Eric Broch wrote:
On 10/2/2018 7:34 PM, Andrew Swartz wrote:
1. vpopmail (or something else) is NOW authenticating
I don't think so, or I hope not. I've done nothing except
cleartext password instead of the hash.
vpopmail on CentOS 7 back in 2015 no patches.
The only change, if I remember correctly, is MariaDB
2. vpopmail (or something else) is NOW truncating the
characters when it is set (i.e. hashed), but not during
I hope it's something else.
3. mysql was storing something in the cleartext password
did not export. This seems unlikely, as I can see 16
field type is "char(16)". I went through the database export
its contents appear the same as those of the running mysql
Centos5, which is the same as the running mariadb database on
view the contents with WebMin). Therefore it appears that
backup/restore worked properly.
Maybe something worth my time: Bring up two qmail (w/vpopmail)
COS5 and COS7.
Next, Create a domain and user entry on COS5 with >16 length
Dump the vpopmail db on COS5 (vpopmail-cos5db), and import
Dump the vpopmail db on COS7 (vpopmail-cos7db), and compare
If they're the same it could possibly be an issue with the
If you were up to it, you could also create a database called
on your COS7 machine,
and import the COS5 vpopmail db into it (that way it doesn't
your regular vpopmail db), and
dump it and compare the two (COS5/COS7) dumps.
Does anyone know the details of how vpopmail interacts
server? Or if any authentication is done by some means
Interaction with db by vpopmail is done at compile time.
White Horse Technical Consulting (WHTC)