I'm not convinced that the way QMT has set up the vpopmail configuration
is the best way to go.
I'd have preferred the '--disable-many-domains' option for vpopmail
which would have facilitated dovecot's use of it's mysql script and this
problem would go away FAST...with a change in SQL, but to change it now
might make migration a nightmare.
If someone is migrating and they think there are >16 character length
passwords, dump the vpopmail database, then, set all clear passwords to
null and dump it again. Use the second dump as your import on the new
host. Keep the original because it might make you feel good, it would
me. ;-)
On 10/3/2018 12:28 AM, Eric Broch wrote:
It would be very easy to compile vpopmail disabling clear passwords,
but the immediate problem for those migrating is the fact that the
clear password already exists and changing vpopmail wouldn't deal with
existing accounts.
Only newly created accounts would have 'null' clear text passwords.
Also, the hash used by vpopmail is MD5 by default which QMT utilizes,
DES is also available.
On 10/3/2018 12:10 AM, Andrew Swartz wrote:
Eric,
Excellent test with very useful results!
Modern security practice would indicate elimination of the cleartext
passwords. How difficult would it be compile vpopmail without cleartext
passwords?
I propose two reasons for this path:
1) The one of the biggest reasons to use qmail is it's security record.
We should try as much a possible to make the accessories as secure as
qmail. There are a lot of people who would not use QMT because storage
of cleartext passwords SOUNDS medieval and dangerous at this point,
regardless of whether or not it is. My understanding is that DJB wrote
the qmail modules with each assuming that the others had been
compromised. I think that the qmail accessories should be configured
using this same philosophy as much as possible. Assuming that no
intruder could ever get in or get root access is a path to making lots
poor decisions which could eventually be regretted.
2) Using only the hash allows infinite size passwords. Admittedly, 40
characters sounds adequate. But that might be eventually outgrown and
we would have the same problem again. But any size password will always
yield the same size hash.
One extra thought:
If vpopmail were to be patched or recompiled, one thought might be to
check what hash routine it uses. If it is weaker than SHA256, it
probably ought to be updated to this or SHA512. I've not looked at the
vpopmail source code so I have no idea if that is feasible. But it
might be quite easy.
-Andy
On 10/2/2018 9:28 PM, 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
authentication,
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.
Any opinions?
On 10/2/2018 11:21 PM, Eric Broch wrote:
Dovecot will authenticate against the clear text password if it is
present.
Upon updating the clear text password (encrypted 17 characters) to
'null', I authenticated using Dovecot against the 17 character
password.
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
='user';
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
Dovecot
directly accessing the database. Given that the hash cannot be
reversed, the only way to get the cleartext password is direct
database
access.
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
allows
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
probably a
much bigger disadvantage.
-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.
--
Eric Broch
White Horse Technical Consulting (WHTC)
---------------------------------------------------------------------
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
