I would say change to 40 chars Remo
-- > On Tuesday, Oct 02, 2018 at 22:29, Eric Broch <[email protected] > (mailto:[email protected])> 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] >
signature.asc
Description: PGP signature
