+1
> On Oct 3, 2018, at 12:35, Dan McAllister - QMT DNS <[email protected]> wrote: > > I have read this thread somewhat thoroughly, but not particularly carefully. > But, that being said... unless I missed something, here's my take: > - QMail "proper" (that is, the SMTP servers) already "properly" authenticates > based on the hash in the vpopmail database -- which is indeed salted. > When you dump the hash value, you will find a "starter field" that > identifies the HASH algorithm > $1$ is MD5 -- the old default, but admittedly "broken" algorithm, $5$ > is SHA-256, and $6$ is SHA-512... as examples > - Because QMail "properly" authenticates against the hashed passwords, > passwords longer than 16 chars are authenticated properly > - QMailToaster (which is QMail packaged with other things) originally came > packaged with CourierIMAP -- which ALSO used the HASHED password for > authentication, so no problems there: long passwords with long authentication > strings worked perfectly > - The newer DoveCot IMAP server "appears" to be authenticating against the > cleartext password -- which is an ERROR in the DoveCot configuration. > > > I have mentioned earlier that the vqadmin tool that comes with QMailToaster > by default, is in my mind, a BAD TOOL -- it gives ALL access to ANYONE who > can authenticate to it. I DISABLE this link AND the program in my installs. > If users want to administer domains, they have to have been created by CLI, > and they have to use an administrator account on that domain (qmailadmin > interface)... and they can only see 1 domain at a time. > > *IF* you remove the vqadmin tool, the ONLY access to cleartext passwords is > from the CLI (assuming we fix the mal-formed DoveCot we currently have)... > that, to me should be sufficiently secure. Without vqadmin, I am aware of no > other "interface" in QMailToaster that makes cleartext passwords visible -- > except for the vuserinfo command in the shell. > > So... in conclusion, I don't think there is anything wrong in the MySQL or > MariaDB databases -- and changing them could lead to a nightmare of backward > compatibility issues... however, FIXING the DoveCot configuration to use the > 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: Eric Broch <[email protected]> > Sent: Wednesday, October 3, 2018 2:46 AM > To: [email protected] > Subject: Re: [qmailtoaster] Passwords after backup/restore > > 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([email protected],127.0.0.1,<dVsPJ0t3GIl/AAAB>): >>>>>>> CLEARTEXT(xxxxxxxxxxxxxxxxx) != 'xxxxxxxxxxxxxxxx' >>>>>>> Oct 02 22:05:47 auth: Debug: client passdb out: FAIL 1 >>>>>>> [email protected] >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 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: [email protected] > For additional commands, e-mail: [email protected] > > > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
