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
Fixing the backup/restore might not be too difficult. The backup script
exports the database to a text file of comma separated values. Seems
like a clever AWK one-liner could go through that file and set that
field in each line equal to an empty string. Then continue as normal
with the restore s
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.
Tony,
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.
Eric
On 10/3/2018 12:10 AM, Tony White wrote:
Hi Eri
Hi Eric,
I sent an email to the list with a suggestion ages ago.
It has not arrived. Is there some protection against sql code?
best wishes
Tony White
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
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 sec
I would say change to 40 chars
Remo
--
> On Tuesday, Oct 02, 2018 at 22:29, Eric Broch (mailto:ebr...@whitehorsetc.com)> 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 co
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
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>
upda
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
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 p
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,):
CLEARTEXT(x) != 'x
Eric,
On Centos7, I just successfully authenticated for relay on port 587 with
a 26-character password. That same username/password fails with
Squirrelmail. But it works with Squirrelmail if using only the first
16-characters of the password.
Since qmail-smtpd DEFINITELY authenticates through v
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 throu
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 (us
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. Unfor
CentOS 6/7 acting similarly, >16 character length password failed on
both (of mine at least). First 16 characters worked on both.
On 10/2/2018 8:47 PM, Eric Broch wrote:
Okay,
Set user's password to 17 x's, eg: x
I could not log in with 17x password but I could with 16x passw
I remember as I said that the 5.5 had this option enabled. I may be wrong but I
am pretty sure on that.
> On Oct 2, 2018, at 19:47, Eric Broch wrote:
>
> Okay,
>
> Set user's password to 17 x's, eg: x
>
> I could not log in with 17x password but I could with 16x password.
>
Okay,
Set user's password to 17 x's, eg: x
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 wr
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 pass
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 re
I know that the 5.5 had some of those features.. So not sure if that is the
case since we are running 5.4 in QMT.
Remo
--
> On Tuesday, Oct 02, 2018 at 18:35, Andrew Swartz (mailto:awswa...@acsalaska.net)> wrote:
> Has vpopmail changed?
>
> Among the numerous possible explanations of this beha
Has vpopmail changed?
Among the numerous possible explanations of this behavior:
1. vpopmail (or something else) is NOW authenticating against the
cleartext password instead of the hash.
2. vpopmail (or something else) is NOW truncating the password at 16
characters when it is set (i.e. hashed
I would suggest to try MariaDB 10, instead of 5.x and see if that’s still the
case.
Remo
> On Oct 2, 2018, at 17:02, Eric Broch wrote:
>
> This might be worthy of a note to the MariaDB folks.
>
>
> On 10/2/2018 5:59 PM, Andrew Swartz wrote:
>> I felt a new subject appropriate.
>>
>> Curren
This might be worthy of a note to the MariaDB folks.
On 10/2/2018 5:59 PM, Andrew Swartz wrote:
I felt a new subject appropriate.
Current setup is QMT on Centos7 (set up last month). I did a
backup/restore (of accounts only) from a Centos5 QMT.
NEW INFORMATION:
I just dug through a few autom
I felt a new subject appropriate.
Current setup is QMT on Centos7 (set up last month). I did a
backup/restore (of accounts only) from a Centos5 QMT.
NEW INFORMATION:
I just dug through a few automated accounts which still have the long
passwords which I've not updated since the backup/restore.
I had the issue.
I merely fixed it rather than fully investigating it.
I had some accounts where, after the backup/restore, the passwords
worked fine. Yet other where the passwords failed. When I looked at
the database, the ones where the passwords failed had a long cleartext
password which was
No problem, Tony. I understood.
I know that corruption can happen, which is an inevitable result of the
software world, but using the standard MySQL/MariaDB tools doesn't
(generally) invite it, IMHO. That is, an encrypted password (a text,
CHAR, field) will remain the same, barring aforementio
Hi Eric,
Sorry, I made it sound like you had the issue. I know it was not you.
best wishes
Tony White
On 03/10/18 07:50, Eric Broch wrote:
Okay,
It seems odd, to me at least, that using the mysql/mariadb commands 'mysqldump' to backup the vpopmail database and to
restore it again with 'm
Hi Eric,
Having just done this for my migration from COS 5 to 6 I have not come across
this problem.
I have just verified a few accounts using vuserinfo and comparing the results
between the old server
and new and they are identical.
Is it possible you had old_passwords set on the old server
Okay,
It seems odd, to me at least, that using the mysql/mariadb commands
'mysqldump' to backup the vpopmail database and to restore it again with
'mysql -u xxx -pyyy vpopmail < db' yields a corrupt database. How is
this possible? Certainly a backup/restore doesn't rehash passwords using
the
I hear ya Andrew! I have a very large QMT that hosts hundreds of domains. One
of those tenants knows that this is a QMT install, and wanted to have access to
the vqadmin program -- which WOULD have given them visibility to other domains'
passwords -- but I deny access to that tool to anyone (I d
Dan,
Excellent explanation. Thank you.
It explains something which I did not report in my email: I solved this
by trying only the first 16 characters of the long passwords, and sure
enough they validated. I did not put enough thought into it to realize
that the hashes had been regenerated from
Thanks, Dan.
On 10/2/2018 7:02 AM, Dan McAllister - QMT DNS wrote:
I know I'm "Johnny-come-lately" on this topic, but I can explain the results
you're seeing and have seen the same myself:
The QMT vpopmail default setup saves the hashed password, as well as the first
16-characters of the cle
I know I'm "Johnny-come-lately" on this topic, but I can explain the results
you're seeing and have seen the same myself:
The QMT vpopmail default setup saves the hashed password, as well as the first
16-characters of the clear-text password, in the MySQL database. That has
already been establi
36 matches
Mail list logo
