can support/recognize those other
algorithms.
Dan
-Original Message-----
From: Eric Broch
Sent: Wednesday, October 3, 2018 4:34 PM
To: qmailtoaster-list@qmailtoaster.com
Subject: Re: [qmailtoaster] Passwords after backup/restore
The newer DoveCot IMAP server "appears" to be authe
NOT a backward compatibility
>>> issue with updating our algorithms because the mechanism is CODED to
>>> show which algorithm is used (the $1$ currently there, maybe a $6$ in
>>> the future?)
>>>
>>> However, we would need to check with the qmail code, as w
d (the $1$ currently there, maybe a $6$ in
the future?)
However, we would need to check with the qmail code, as well as
DoveCot, to determine if they can support/recognize those other
algorithms.
Dan
-Original Message-
From: Eric Broch
Sent: Wednesday, October 3, 2018 4:34 PM
To:
r-list@qmailtoaster.com
Subject: Re: [qmailtoaster] Passwords after backup/restore
The newer DoveCot IMAP server "appears" to be authenticating against
the cleartext password
It does. I checked the code.
I've submitted a question to the Dovecot mailing list concerning this, that is,
whet
with the qmail code, as well as DoveCot, to
> determine if they can support/recognize those other algorithms.
>
> Dan
>
> -Original Message-
> From: Eric Broch
> Sent: Wednesday, October 3, 2018 4:34 PM
> To: qmailtoaster-list@qmailtoaster.com
> Subject: Re: [q
passwords?
Dan
-Original Message-
From: Eric Broch
Sent: Wednesday, October 3, 2018 5:49 PM
To: qmailtoaster-list@qmailtoaster.com
Subject: Re: [qmailtoaster] Passwords after backup/restore
In the mean time, I've written a script to null the clear text pwd field, look
at it, TEST IT,
ail code, as well as DoveCot, to
determine if they can support/recognize those other algorithms.
Dan
-Original Message-
From: Eric Broch
Sent: Wednesday, October 3, 2018 4:34 PM
To: qmailtoaster-list@qmailtoaster.com
Subject: Re: [qmailtoaster] Passwords after backup/restore
Th
The newer DoveCot IMAP server "appears" to be authenticating against the
cleartext password
It does. I checked the code.
I've submitted a question to the Dovecot mailing list concerning this,
that is, whether there is a configuration option to authorize against
the hash, or whether there is a
e
> appropriate AUTH (e.g. HASH and not CLEARTEXT) mechanism would seem to be in
> order and an IMPORTANT update to the system.
>
> Just my thoughts...
>
> Dan McAllister
> QMT DNS/Mirror Admin (semi-retired)
>
> -Original Message-
> From: Er
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.
36 matches
Mail list logo
