Re: [qmailtoaster] Passwords after backup/restore
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 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,): > > > > CLEARTEXT(x) != '' > > > > 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
Re: [qmailtoaster] Passwords after backup/restore
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,): CLEARTEXT(x) != '' 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: 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 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
Re: [qmailtoaster] Passwords after backup/restore
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,): CLEARTEXT(x) != '' 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: 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 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
Re: [qmailtoaster] Passwords after backup/restore
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,): > CLEARTEXT(x) != '' > 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: 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 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, >
Re: [qmailtoaster] Passwords after backup/restore
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 passwords. I have little SQL knowledge and even less experience, so I'm not brave enough to try this on my system. :) -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,): > CLEARTEXT(x) != '' > 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: 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 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
Re: [qmailtoaster] Passwords after backup/restore
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) != '' 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: 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 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
Re: [qmailtoaster] Passwords after backup/restore
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 vpopmail, I think that this indicates that both vpopmail and the database are functioning correctly. I originally found this problem because my IMAP client (Thunderbird) was getting long passwords rejected. Since Squirrelmail also authenticates through IMAP, this suggests that Dovecot is the problem. I hope that Dovecot is not directly accessing the database (i.e. bypassing vpopmail) and authenticating with the cleartext (truncation of) the password. I'm open to other theories which can explain this behavior. -Andy On 10/2/2018 7: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: 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 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
Re: [qmailtoaster] Passwords after backup/restore
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: 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 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
Re: [qmailtoaster] Passwords after backup/restore
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: 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 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
Re: [qmailtoaster] Passwords after backup/restore
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: 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 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. >> > smime.p7s Description: S/MIME Cryptographic Signature
Re: [qmailtoaster] Passwords after backup/restore
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 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
Re: [qmailtoaster] Passwords after backup/restore
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. > > 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 > - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Passwords after backup/restore
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 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
Re: [qmailtoaster] Passwords after backup/restore
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
Re: [qmailtoaster] Passwords after backup/restore
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. > smime.p7s Description: S/MIME Cryptographic Signature
Re: [qmailtoaster] Passwords after backup/restore
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
Re: [qmailtoaster] Passwords after backup/restore
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 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), but not during subsequent > authentication. > > 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. > > 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? > > -Andy > > > > On 10/2/2018 4:02 PM, 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. > > > > > > 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 tried > > > logging in via Squirelmail. > > > > > > - I cannot authenticate with the long password. > > > - I CAN authenticate with the first 16 characters of the password. > > > - The hashes in the old (Centos5) and new (Centos7) vpopmail databases > > > are identical. Therefore it Eric seems correct that the restore did not > > > regenerate the hashes. > > > > > > HOWEVER: > > > I just tried the same account/password on the old Centos5 QMT, and > > > successfully logged in with the long password (via squirrelmail). > > > > > > NEXT: > > > I just took a test account with a short password on the Centos7 QMT, and > > > I reset it to a long. > > > - I cannot authenticate with the long password. > > > - I CAN authenticate with the first 16 characters of the password. > > > > > > > > > The only thing I can say conclusively is that this is different behavior > > > than on my Centos5 QMT where I was authenticating with long passwords > > > and never had any such problems. > > > > > > It seems that the different before/after behavior is not due to the > > > backup/restore scripts, but rather to some sort of different > > > functionality of the Centos7 setup. It may take a lot of digging and > > > expert knowledge to sort this out. > > > > > > Curious to hear if others can replicate this behavior. > > > > > > > > > -Andy > > > > > > > > > > > > > > > > > > > > > On 10/2/2018 3:19 PM, Andrew Swartz wrote: > > > > 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 chopped off at 16 characters. All the accounts with > > > > short passwords worked fine. I looked at the database schema, and saw > > > > that the cleartext password field is 16 characters. So I tried > > > > authenticating with the shortened version of the password, and I > > > > ~believe~ that it worked. However, I figured that there was now a > > > > discrepancy between the cleartext and the hash, so I reset the passwords > > > > for all the affected accounts. > > > > > > > > In retrospect, I wish I had investigated further; however, I was in the > > > > mode of fixing the problem as rapidly as possible. I apologize for not > > > > digging further so that I could pass the info along to others. > > > > > > > > I do not remember if I visually compared the hashes. I probably did, > > > > and they were probably the same. That is probably why I got worried > > > > about a cleartext versus hash discrepancy. > > > > > > > > This much I can say with 100% confidence: > > > > The accounts with passwords >16 characters would not authenticate after > > > > the backup/restore procedure. Resetting those passwords fixed the > > > > problem. > > > > > > > > > > > > -Andy > > > > > > > > > > > > > > > > On 10/2/2018 2:49 PM, Tony White wrote: > > > > > 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: > > > > > > > > > > >
Re: [qmailtoaster] Passwords after backup/restore
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), but not during subsequent authentication. 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. 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? -Andy On 10/2/2018 4:02 PM, 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. >> >> 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 tried >> logging in via Squirelmail. >> >> - I cannot authenticate with the long password. >> - I CAN authenticate with the first 16 characters of the password. >> - The hashes in the old (Centos5) and new (Centos7) vpopmail databases >> are identical. Therefore it Eric seems correct that the restore did not >> regenerate the hashes. >> >> HOWEVER: >> I just tried the same account/password on the old Centos5 QMT, and >> successfully logged in with the long password (via squirrelmail). >> >> NEXT: >> I just took a test account with a short password on the Centos7 QMT, and >> I reset it to a long. >> - I cannot authenticate with the long password. >> - I CAN authenticate with the first 16 characters of the password. >> >> >> The only thing I can say conclusively is that this is different behavior >> than on my Centos5 QMT where I was authenticating with long passwords >> and never had any such problems. >> >> It seems that the different before/after behavior is not due to the >> backup/restore scripts, but rather to some sort of different >> functionality of the Centos7 setup. It may take a lot of digging and >> expert knowledge to sort this out. >> >> Curious to hear if others can replicate this behavior. >> >> >> -Andy >> >> >> >> >> >> >> On 10/2/2018 3:19 PM, Andrew Swartz wrote: >>> 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 chopped off at 16 characters. All the accounts with >>> short passwords worked fine. I looked at the database schema, and saw >>> that the cleartext password field is 16 characters. So I tried >>> authenticating with the shortened version of the password, and I >>> ~believe~ that it worked. However, I figured that there was now a >>> discrepancy between the cleartext and the hash, so I reset the passwords >>> for all the affected accounts. >>> >>> In retrospect, I wish I had investigated further; however, I was in the >>> mode of fixing the problem as rapidly as possible. I apologize for not >>> digging further so that I could pass the info along to others. >>> >>> I do not remember if I visually compared the hashes. I probably did, >>> and they were probably the same. That is probably why I got worried >>> about a cleartext versus hash discrepancy. >>> >>> This much I can say with 100% confidence: >>> The accounts with passwords >16 characters would not authenticate after >>> the backup/restore procedure. Resetting those passwords fixed the >>> problem. >>> >>> >>> -Andy >>> >>> >>> >>> On 10/2/2018 2:49 PM, Tony White wrote: 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 'mysql -u xxx -pyyy vpopmail < db' yields a corrupt database. How > is this possible? Certainly a backup/restore doesn't rehash passwords > using the clear text field. It should simply restore exactly what's > backed up. Is this thinking erroneous??? > > Eric > > > On 10/2/2018 12:09 PM, Dan McAllister - QMT DNS wrote: >> I hear ya Andrew! I have a very large QMT
Re: [qmailtoaster] Passwords after backup/restore
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. >> >> 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 tried >> logging in via Squirelmail. >> >> - I cannot authenticate with the long password. >> - I CAN authenticate with the first 16 characters of the password. >> - The hashes in the old (Centos5) and new (Centos7) vpopmail databases >> are identical. Therefore it Eric seems correct that the restore did not >> regenerate the hashes. >> >> HOWEVER: >> I just tried the same account/password on the old Centos5 QMT, and >> successfully logged in with the long password (via squirrelmail). >> >> NEXT: >> I just took a test account with a short password on the Centos7 QMT, and >> I reset it to a long. >> - I cannot authenticate with the long password. >> - I CAN authenticate with the first 16 characters of the password. >> >> >> The only thing I can say conclusively is that this is different behavior >> than on my Centos5 QMT where I was authenticating with long passwords >> and never had any such problems. >> >> It seems that the different before/after behavior is not due to the >> backup/restore scripts, but rather to some sort of different >> functionality of the Centos7 setup. It may take a lot of digging and >> expert knowledge to sort this out. >> >> Curious to hear if others can replicate this behavior. >> >> >> -Andy >> >> >> >> >> >> >> On 10/2/2018 3:19 PM, Andrew Swartz wrote: >>> 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 chopped off at 16 characters. All the accounts with >>> short passwords worked fine. I looked at the database schema, and saw >>> that the cleartext password field is 16 characters. So I tried >>> authenticating with the shortened version of the password, and I >>> ~believe~ that it worked. However, I figured that there was now a >>> discrepancy between the cleartext and the hash, so I reset the passwords >>> for all the affected accounts. >>> >>> In retrospect, I wish I had investigated further; however, I was in the >>> mode of fixing the problem as rapidly as possible. I apologize for not >>> digging further so that I could pass the info along to others. >>> >>> I do not remember if I visually compared the hashes. I probably did, >>> and they were probably the same. That is probably why I got worried >>> about a cleartext versus hash discrepancy. >>> >>> This much I can say with 100% confidence: >>> The accounts with passwords >16 characters would not authenticate after >>> the backup/restore procedure. Resetting those passwords fixed the problem. >>> >>> >>> -Andy >>> >>> >>> >>> On 10/2/2018 2:49 PM, Tony White wrote: 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 'mysql -u xxx -pyyy vpopmail < db' yields a corrupt database. How > is this possible? Certainly a backup/restore doesn't rehash passwords > using the clear text field. It should simply restore exactly what's > backed up. Is this thinking erroneous??? > > Eric > > > On 10/2/2018 12:09 PM, Dan McAllister - QMT DNS wrote: >> 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 don't even use it)... they CAN use >> the admin role with the standard qmailadmin interface, because that >> is limited to one domain at a time. >> >> I have a list of "superadmins" for that system that have access to >> the user passwords through the shell "vuserinfo" command -- and you >> have to be elevated (root) to run that, so anyone breaking in >> (hacking) the website (apache user), or qmail (qmail, qmaill, or >> qmailq users) or even vpopmail (vpopmail user) will NOT be able to >> run that command. >> >>
Re: [qmailtoaster] Passwords after backup/restore
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 automated accounts which still have the long passwords which I've not updated since the backup/restore. I tried logging in via Squirelmail. - I cannot authenticate with the long password. - I CAN authenticate with the first 16 characters of the password. - The hashes in the old (Centos5) and new (Centos7) vpopmail databases are identical. Therefore it Eric seems correct that the restore did not regenerate the hashes. HOWEVER: I just tried the same account/password on the old Centos5 QMT, and successfully logged in with the long password (via squirrelmail). NEXT: I just took a test account with a short password on the Centos7 QMT, and I reset it to a long. - I cannot authenticate with the long password. - I CAN authenticate with the first 16 characters of the password. The only thing I can say conclusively is that this is different behavior than on my Centos5 QMT where I was authenticating with long passwords and never had any such problems. It seems that the different before/after behavior is not due to the backup/restore scripts, but rather to some sort of different functionality of the Centos7 setup. It may take a lot of digging and expert knowledge to sort this out. Curious to hear if others can replicate this behavior. -Andy On 10/2/2018 3:19 PM, Andrew Swartz wrote: 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 chopped off at 16 characters. All the accounts with short passwords worked fine. I looked at the database schema, and saw that the cleartext password field is 16 characters. So I tried authenticating with the shortened version of the password, and I ~believe~ that it worked. However, I figured that there was now a discrepancy between the cleartext and the hash, so I reset the passwords for all the affected accounts. In retrospect, I wish I had investigated further; however, I was in the mode of fixing the problem as rapidly as possible. I apologize for not digging further so that I could pass the info along to others. I do not remember if I visually compared the hashes. I probably did, and they were probably the same. That is probably why I got worried about a cleartext versus hash discrepancy. This much I can say with 100% confidence: The accounts with passwords >16 characters would not authenticate after the backup/restore procedure. Resetting those passwords fixed the problem. -Andy On 10/2/2018 2:49 PM, Tony White wrote: 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 'mysql -u xxx -pyyy vpopmail < db' yields a corrupt database. How is this possible? Certainly a backup/restore doesn't rehash passwords using the clear text field. It should simply restore exactly what's backed up. Is this thinking erroneous??? Eric On 10/2/2018 12:09 PM, Dan McAllister - QMT DNS wrote: 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 don't even use it)... they CAN use the admin role with the standard qmailadmin interface, because that is limited to one domain at a time. I have a list of "superadmins" for that system that have access to the user passwords through the shell "vuserinfo" command -- and you have to be elevated (root) to run that, so anyone breaking in (hacking) the website (apache user), or qmail (qmail, qmaill, or qmailq users) or even vpopmail (vpopmail user) will NOT be able to run that command. I also CHANGE the default passwords for the MySQL database... so if you CAN break in, you CANNOT just query the database (because the vpopmail password is well known). So that's been my way to deal with it... your mileage may vary Dan -Original Message- From: Andrew Swartz Sent: Tuesday, October 2, 2018 11:24 AM To: qmailtoaster-list@qmailtoaster.com Subject: Re: Fwd: Re: [qmailtoaster] centos 6 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
[qmailtoaster] Passwords after backup/restore
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 tried logging in via Squirelmail. - I cannot authenticate with the long password. - I CAN authenticate with the first 16 characters of the password. - The hashes in the old (Centos5) and new (Centos7) vpopmail databases are identical. Therefore it Eric seems correct that the restore did not regenerate the hashes. HOWEVER: I just tried the same account/password on the old Centos5 QMT, and successfully logged in with the long password (via squirrelmail). NEXT: I just took a test account with a short password on the Centos7 QMT, and I reset it to a long. - I cannot authenticate with the long password. - I CAN authenticate with the first 16 characters of the password. The only thing I can say conclusively is that this is different behavior than on my Centos5 QMT where I was authenticating with long passwords and never had any such problems. It seems that the different before/after behavior is not due to the backup/restore scripts, but rather to some sort of different functionality of the Centos7 setup. It may take a lot of digging and expert knowledge to sort this out. Curious to hear if others can replicate this behavior. -Andy On 10/2/2018 3:19 PM, Andrew Swartz wrote: > 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 chopped off at 16 characters. All the accounts with > short passwords worked fine. I looked at the database schema, and saw > that the cleartext password field is 16 characters. So I tried > authenticating with the shortened version of the password, and I > ~believe~ that it worked. However, I figured that there was now a > discrepancy between the cleartext and the hash, so I reset the passwords > for all the affected accounts. > > In retrospect, I wish I had investigated further; however, I was in the > mode of fixing the problem as rapidly as possible. I apologize for not > digging further so that I could pass the info along to others. > > I do not remember if I visually compared the hashes. I probably did, > and they were probably the same. That is probably why I got worried > about a cleartext versus hash discrepancy. > > This much I can say with 100% confidence: > The accounts with passwords >16 characters would not authenticate after > the backup/restore procedure. Resetting those passwords fixed the problem. > > > -Andy > > > > On 10/2/2018 2:49 PM, Tony White wrote: >> 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 'mysql -u xxx -pyyy vpopmail < db' yields a corrupt database. How >>> is this possible? Certainly a backup/restore doesn't rehash passwords >>> using the clear text field. It should simply restore exactly what's >>> backed up. Is this thinking erroneous??? >>> >>> Eric >>> >>> >>> On 10/2/2018 12:09 PM, Dan McAllister - QMT DNS wrote: 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 don't even use it)... they CAN use the admin role with the standard qmailadmin interface, because that is limited to one domain at a time. I have a list of "superadmins" for that system that have access to the user passwords through the shell "vuserinfo" command -- and you have to be elevated (root) to run that, so anyone breaking in (hacking) the website (apache user), or qmail (qmail, qmaill, or qmailq users) or even vpopmail (vpopmail user) will NOT be able to run that command. I also CHANGE the default passwords for the MySQL database... so if you CAN break in, you CANNOT just query the database (because the vpopmail password is well known). So that's been my way to deal with it... your mileage may vary Dan -Original Message- From: Andrew Swartz Sent: Tuesday, October 2, 2018 11:24 AM To: qmailtoaster-list@qmailtoaster.com Subject: Re: Fwd: Re: [qmailtoaster] centos 6 Dan, Excellent explanation. Thank you.
Re: Fwd: Re: [qmailtoaster] centos 6
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 chopped off at 16 characters. All the accounts with short passwords worked fine. I looked at the database schema, and saw that the cleartext password field is 16 characters. So I tried authenticating with the shortened version of the password, and I ~believe~ that it worked. However, I figured that there was now a discrepancy between the cleartext and the hash, so I reset the passwords for all the affected accounts. In retrospect, I wish I had investigated further; however, I was in the mode of fixing the problem as rapidly as possible. I apologize for not digging further so that I could pass the info along to others. I do not remember if I visually compared the hashes. I probably did, and they were probably the same. That is probably why I got worried about a cleartext versus hash discrepancy. This much I can say with 100% confidence: The accounts with passwords >16 characters would not authenticate after the backup/restore procedure. Resetting those passwords fixed the problem. -Andy On 10/2/2018 2:49 PM, Tony White wrote: > 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 'mysql -u xxx -pyyy vpopmail < db' yields a corrupt database. How >> is this possible? Certainly a backup/restore doesn't rehash passwords >> using the clear text field. It should simply restore exactly what's >> backed up. Is this thinking erroneous??? >> >> Eric >> >> >> On 10/2/2018 12:09 PM, Dan McAllister - QMT DNS wrote: >>> 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 don't even use it)... they CAN use >>> the admin role with the standard qmailadmin interface, because that >>> is limited to one domain at a time. >>> >>> I have a list of "superadmins" for that system that have access to >>> the user passwords through the shell "vuserinfo" command -- and you >>> have to be elevated (root) to run that, so anyone breaking in >>> (hacking) the website (apache user), or qmail (qmail, qmaill, or >>> qmailq users) or even vpopmail (vpopmail user) will NOT be able to >>> run that command. >>> >>> I also CHANGE the default passwords for the MySQL database... so if >>> you CAN break in, you CANNOT just query the database (because the >>> vpopmail password is well known). >>> >>> So that's been my way to deal with it... your mileage may vary >>> >>> Dan >>> >>> >>> -Original Message- >>> From: Andrew Swartz >>> Sent: Tuesday, October 2, 2018 11:24 AM >>> To: qmailtoaster-list@qmailtoaster.com >>> Subject: Re: Fwd: Re: [qmailtoaster] centos 6 >>> >>> 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 the shortened passwords. >>> >>> This explanation implies that the problem is that the restore script >>> generates new hashes from the [stored] cleartext passwords. Seems like >>> an easy fix would be to just backup/restore the hashes instead of >>> generating new hashes. >>> >>> QUESTIONS: >>> 1. What is the format of the stored hash? Looks like concatenation of >>> two [atypical] base64 fields. >>> >>> 2. How difficult would it be to remove the cleartext passwords from >>> vpopmail? I see the logic of storing the "hint". But it means that for >>> systems with multiple admins, all of the admins can view (and therefore >>> use) most users' passwords. That is problematic even without >>> considering the foreign intruder risk. >>> >>> My security concern for QMT has always been that I've never trusted the >>> qmail accessories as much as qmail itself. I remain fairly confident >>> that an intruder will not enter via port 25 (i.e. through qmail). But >>> running the web server (for webmail) markedly increases the risk. >>> >>> QUESTION: could a webserver SQL-injection retrieve the cleartext >>> passwords? >>> >>> -Andy >>> >>> >>> >>> On 10/2/2018 5: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:
Re: Fwd: Re: [qmailtoaster] centos 6
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 aforementioned corruption, across databases and their fields on migration. On 10/2/2018 4:49 PM, Tony White wrote: 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 'mysql -u xxx -pyyy vpopmail < db' yields a corrupt database. How is this possible? Certainly a backup/restore doesn't rehash passwords using the clear text field. It should simply restore exactly what's backed up. Is this thinking erroneous??? Eric On 10/2/2018 12:09 PM, Dan McAllister - QMT DNS wrote: 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 don't even use it)... they CAN use the admin role with the standard qmailadmin interface, because that is limited to one domain at a time. I have a list of "superadmins" for that system that have access to the user passwords through the shell "vuserinfo" command -- and you have to be elevated (root) to run that, so anyone breaking in (hacking) the website (apache user), or qmail (qmail, qmaill, or qmailq users) or even vpopmail (vpopmail user) will NOT be able to run that command. I also CHANGE the default passwords for the MySQL database... so if you CAN break in, you CANNOT just query the database (because the vpopmail password is well known). So that's been my way to deal with it... your mileage may vary Dan -Original Message- From: Andrew Swartz Sent: Tuesday, October 2, 2018 11:24 AM To: qmailtoaster-list@qmailtoaster.com Subject: Re: Fwd: Re: [qmailtoaster] centos 6 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 the shortened passwords. This explanation implies that the problem is that the restore script generates new hashes from the [stored] cleartext passwords. Seems like an easy fix would be to just backup/restore the hashes instead of generating new hashes. QUESTIONS: 1. What is the format of the stored hash? Looks like concatenation of two [atypical] base64 fields. 2. How difficult would it be to remove the cleartext passwords from vpopmail? I see the logic of storing the "hint". But it means that for systems with multiple admins, all of the admins can view (and therefore use) most users' passwords. That is problematic even without considering the foreign intruder risk. My security concern for QMT has always been that I've never trusted the qmail accessories as much as qmail itself. I remain fairly confident that an intruder will not enter via port 25 (i.e. through qmail). But running the web server (for webmail) markedly increases the risk. QUESTION: could a webserver SQL-injection retrieve the cleartext passwords? -Andy On 10/2/2018 5: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 clear-text password, in the MySQL database. That has already been established. What you probably don't know (or didn't think of) is how those fields are used! Consider the following: - First, the length of the hashing algorithm is a fixed length. Different hashes, different lengths (for example: MD5 hashes are always 32 characters, SHA1 hashes have 40 characters, sha512 hashes 128, and so on...) - Second, ONLY the hashed password is used for validation. There is no NEED for the cleartext password in the database, it's there simply because the MySQL database was considered somewhat secure, and the original developers of the QMT realized that about 40% of user problems are caused by NOT KNOWING THEIR PASSWORDS, and being able to GIVE them their existing password was generally easier than resetting it (and hearing complaints that, although you "fixed" their desktop mail, now their phone's weren't getting email!) - Finally, the original designers of QMT assumed people would use long passwords -- it was suggested in the original documentation. Thus, saving only the first 16 characters of the
Re: Fwd: Re: [qmailtoaster] centos 6
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 'mysql -u xxx -pyyy vpopmail < db' yields a corrupt database. How is this possible? Certainly a backup/restore doesn't rehash passwords using the clear text field. It should simply restore exactly what's backed up. Is this thinking erroneous??? Eric On 10/2/2018 12:09 PM, Dan McAllister - QMT DNS wrote: 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 don't even use it)... they CAN use the admin role with the standard qmailadmin interface, because that is limited to one domain at a time. I have a list of "superadmins" for that system that have access to the user passwords through the shell "vuserinfo" command -- and you have to be elevated (root) to run that, so anyone breaking in (hacking) the website (apache user), or qmail (qmail, qmaill, or qmailq users) or even vpopmail (vpopmail user) will NOT be able to run that command. I also CHANGE the default passwords for the MySQL database... so if you CAN break in, you CANNOT just query the database (because the vpopmail password is well known). So that's been my way to deal with it... your mileage may vary Dan -Original Message- From: Andrew Swartz Sent: Tuesday, October 2, 2018 11:24 AM To: qmailtoaster-list@qmailtoaster.com Subject: Re: Fwd: Re: [qmailtoaster] centos 6 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 the shortened passwords. This explanation implies that the problem is that the restore script generates new hashes from the [stored] cleartext passwords. Seems like an easy fix would be to just backup/restore the hashes instead of generating new hashes. QUESTIONS: 1. What is the format of the stored hash? Looks like concatenation of two [atypical] base64 fields. 2. How difficult would it be to remove the cleartext passwords from vpopmail? I see the logic of storing the "hint". But it means that for systems with multiple admins, all of the admins can view (and therefore use) most users' passwords. That is problematic even without considering the foreign intruder risk. My security concern for QMT has always been that I've never trusted the qmail accessories as much as qmail itself. I remain fairly confident that an intruder will not enter via port 25 (i.e. through qmail). But running the web server (for webmail) markedly increases the risk. QUESTION: could a webserver SQL-injection retrieve the cleartext passwords? -Andy On 10/2/2018 5: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 clear-text password, in the MySQL database. That has already been established. What you probably don't know (or didn't think of) is how those fields are used! Consider the following: - First, the length of the hashing algorithm is a fixed length. Different hashes, different lengths (for example: MD5 hashes are always 32 characters, SHA1 hashes have 40 characters, sha512 hashes 128, and so on...) - Second, ONLY the hashed password is used for validation. There is no NEED for the cleartext password in the database, it's there simply because the MySQL database was considered somewhat secure, and the original developers of the QMT realized that about 40% of user problems are caused by NOT KNOWING THEIR PASSWORDS, and being able to GIVE them their existing password was generally easier than resetting it (and hearing complaints that, although you "fixed" their desktop mail, now their phone's weren't getting email!) - Finally, the original designers of QMT assumed people would use long passwords -- it was suggested in the original documentation. Thus, saving only the first 16 characters of the password in cleartext meant you were only REALLY saving a "password hint" vs. the entire password. So - when you enter a 75 character password (only slightly absurd these days), and if we assume a sha1 password hash, then the "set password" function hashes your 75 characters into a 40-character SHA1 hash and saves it into the database field that stores up to (magically) 40 characters. (FWIW: when you enter your 2-character
Re: Fwd: Re: [qmailtoaster] centos 6
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 and not on the new? 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 'mysql -u xxx -pyyy vpopmail < db' yields a corrupt database. How is this possible? Certainly a backup/restore doesn't rehash passwords using the clear text field. It should simply restore exactly what's backed up. Is this thinking erroneous??? Eric On 10/2/2018 12:09 PM, Dan McAllister - QMT DNS wrote: 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 don't even use it)... they CAN use the admin role with the standard qmailadmin interface, because that is limited to one domain at a time. I have a list of "superadmins" for that system that have access to the user passwords through the shell "vuserinfo" command -- and you have to be elevated (root) to run that, so anyone breaking in (hacking) the website (apache user), or qmail (qmail, qmaill, or qmailq users) or even vpopmail (vpopmail user) will NOT be able to run that command. I also CHANGE the default passwords for the MySQL database... so if you CAN break in, you CANNOT just query the database (because the vpopmail password is well known). So that's been my way to deal with it... your mileage may vary Dan -Original Message- From: Andrew Swartz Sent: Tuesday, October 2, 2018 11:24 AM To: qmailtoaster-list@qmailtoaster.com Subject: Re: Fwd: Re: [qmailtoaster] centos 6 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 the shortened passwords. This explanation implies that the problem is that the restore script generates new hashes from the [stored] cleartext passwords. Seems like an easy fix would be to just backup/restore the hashes instead of generating new hashes. QUESTIONS: 1. What is the format of the stored hash? Looks like concatenation of two [atypical] base64 fields. 2. How difficult would it be to remove the cleartext passwords from vpopmail? I see the logic of storing the "hint". But it means that for systems with multiple admins, all of the admins can view (and therefore use) most users' passwords. That is problematic even without considering the foreign intruder risk. My security concern for QMT has always been that I've never trusted the qmail accessories as much as qmail itself. I remain fairly confident that an intruder will not enter via port 25 (i.e. through qmail). But running the web server (for webmail) markedly increases the risk. QUESTION: could a webserver SQL-injection retrieve the cleartext passwords? -Andy On 10/2/2018 5: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 clear-text password, in the MySQL database. That has already been established. What you probably don't know (or didn't think of) is how those fields are used! Consider the following: - First, the length of the hashing algorithm is a fixed length. Different hashes, different lengths (for example: MD5 hashes are always 32 characters, SHA1 hashes have 40 characters, sha512 hashes 128, and so on...) - Second, ONLY the hashed password is used for validation. There is no NEED for the cleartext password in the database, it's there simply because the MySQL database was considered somewhat secure, and the original developers of the QMT realized that about 40% of user problems are caused by NOT KNOWING THEIR PASSWORDS, and being able to GIVE them their existing password was generally easier than resetting it (and hearing complaints that, although you "fixed" their desktop mail, now their phone's weren't getting email!) - Finally, the original designers of QMT assumed people would use long passwords -- it was suggested in the original documentation. Thus, saving only the first 16 characters of the password in cleartext meant you were only REALLY saving a "password hint" vs. the entire password. So - when you enter a 75 character password (only slightly absurd these days), and if we assume
Re: Fwd: Re: [qmailtoaster] centos 6
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 clear text field. It should simply restore exactly what's backed up. Is this thinking erroneous??? Eric On 10/2/2018 12:09 PM, Dan McAllister - QMT DNS wrote: 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 don't even use it)... they CAN use the admin role with the standard qmailadmin interface, because that is limited to one domain at a time. I have a list of "superadmins" for that system that have access to the user passwords through the shell "vuserinfo" command -- and you have to be elevated (root) to run that, so anyone breaking in (hacking) the website (apache user), or qmail (qmail, qmaill, or qmailq users) or even vpopmail (vpopmail user) will NOT be able to run that command. I also CHANGE the default passwords for the MySQL database... so if you CAN break in, you CANNOT just query the database (because the vpopmail password is well known). So that's been my way to deal with it... your mileage may vary Dan -Original Message- From: Andrew Swartz Sent: Tuesday, October 2, 2018 11:24 AM To: qmailtoaster-list@qmailtoaster.com Subject: Re: Fwd: Re: [qmailtoaster] centos 6 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 the shortened passwords. This explanation implies that the problem is that the restore script generates new hashes from the [stored] cleartext passwords. Seems like an easy fix would be to just backup/restore the hashes instead of generating new hashes. QUESTIONS: 1. What is the format of the stored hash? Looks like concatenation of two [atypical] base64 fields. 2. How difficult would it be to remove the cleartext passwords from vpopmail? I see the logic of storing the "hint". But it means that for systems with multiple admins, all of the admins can view (and therefore use) most users' passwords. That is problematic even without considering the foreign intruder risk. My security concern for QMT has always been that I've never trusted the qmail accessories as much as qmail itself. I remain fairly confident that an intruder will not enter via port 25 (i.e. through qmail). But running the web server (for webmail) markedly increases the risk. QUESTION: could a webserver SQL-injection retrieve the cleartext passwords? -Andy On 10/2/2018 5: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 clear-text password, in the MySQL database. That has already been established. What you probably don't know (or didn't think of) is how those fields are used! Consider the following: - First, the length of the hashing algorithm is a fixed length. Different hashes, different lengths (for example: MD5 hashes are always 32 characters, SHA1 hashes have 40 characters, sha512 hashes 128, and so on...) - Second, ONLY the hashed password is used for validation. There is no NEED for the cleartext password in the database, it's there simply because the MySQL database was considered somewhat secure, and the original developers of the QMT realized that about 40% of user problems are caused by NOT KNOWING THEIR PASSWORDS, and being able to GIVE them their existing password was generally easier than resetting it (and hearing complaints that, although you "fixed" their desktop mail, now their phone's weren't getting email!) - Finally, the original designers of QMT assumed people would use long passwords -- it was suggested in the original documentation. Thus, saving only the first 16 characters of the password in cleartext meant you were only REALLY saving a "password hint" vs. the entire password. So - when you enter a 75 character password (only slightly absurd these days), and if we assume a sha1 password hash, then the "set password" function hashes your 75 characters into a 40-character SHA1 hash and saves it into the database field that stores up to (magically) 40 characters. (FWIW: when you enter your 2-character password of "ok", the sha1 algorithm ALSO generates a 40 character output!). After is stores the hashed password, it ALSO stores the first
RE: Fwd: Re: [qmailtoaster] centos 6
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 don't even use it)... they CAN use the admin role with the standard qmailadmin interface, because that is limited to one domain at a time. I have a list of "superadmins" for that system that have access to the user passwords through the shell "vuserinfo" command -- and you have to be elevated (root) to run that, so anyone breaking in (hacking) the website (apache user), or qmail (qmail, qmaill, or qmailq users) or even vpopmail (vpopmail user) will NOT be able to run that command. I also CHANGE the default passwords for the MySQL database... so if you CAN break in, you CANNOT just query the database (because the vpopmail password is well known). So that's been my way to deal with it... your mileage may vary Dan -Original Message- From: Andrew Swartz Sent: Tuesday, October 2, 2018 11:24 AM To: qmailtoaster-list@qmailtoaster.com Subject: Re: Fwd: Re: [qmailtoaster] centos 6 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 the shortened passwords. This explanation implies that the problem is that the restore script generates new hashes from the [stored] cleartext passwords. Seems like an easy fix would be to just backup/restore the hashes instead of generating new hashes. QUESTIONS: 1. What is the format of the stored hash? Looks like concatenation of two [atypical] base64 fields. 2. How difficult would it be to remove the cleartext passwords from vpopmail? I see the logic of storing the "hint". But it means that for systems with multiple admins, all of the admins can view (and therefore use) most users' passwords. That is problematic even without considering the foreign intruder risk. My security concern for QMT has always been that I've never trusted the qmail accessories as much as qmail itself. I remain fairly confident that an intruder will not enter via port 25 (i.e. through qmail). But running the web server (for webmail) markedly increases the risk. QUESTION: could a webserver SQL-injection retrieve the cleartext passwords? -Andy On 10/2/2018 5: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 clear-text password, in the MySQL database. That > has already been established. What you probably don't know (or didn't think > of) is how those fields are used! > > Consider the following: > - First, the length of the hashing algorithm is a fixed length. Different > hashes, different lengths (for example: MD5 hashes are always 32 characters, > SHA1 hashes have 40 characters, sha512 hashes 128, and so on...) > - Second, ONLY the hashed password is used for validation. There is no NEED > for the cleartext password in the database, it's there simply because the > MySQL database was considered somewhat secure, and the original developers of > the QMT realized that about 40% of user problems are caused by NOT KNOWING > THEIR PASSWORDS, and being able to GIVE them their existing password was > generally easier than resetting it (and hearing complaints that, although you > "fixed" their desktop mail, now their phone's weren't getting email!) > - Finally, the original designers of QMT assumed people would use long > passwords -- it was suggested in the original documentation. Thus, saving > only the first 16 characters of the password in cleartext meant you were only > REALLY saving a "password hint" vs. the entire password. > > So - when you enter a 75 character password (only slightly absurd these > days), and if we assume a sha1 password hash, then the "set password" > function hashes your 75 characters into a 40-character SHA1 hash and saves it > into the database field that stores up to (magically) 40 characters. (FWIW: > when you enter your 2-character password of "ok", the sha1 algorithm ALSO > generates a 40 character output!). After is stores the hashed password, it > ALSO stores the first 16 characters of the cleartext password -- because > that's the length of the field in the database. > > When you try to authenticate, the password you provided is re-hashed > (regardless of its length -- although usually those fields have 64, 72, or > 128 character field limits - depending on the web-page designer/programmer), > and those 40 characters (the output of the sha1 hash) are compared
Re: Fwd: Re: [qmailtoaster] centos 6
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 the shortened passwords. This explanation implies that the problem is that the restore script generates new hashes from the [stored] cleartext passwords. Seems like an easy fix would be to just backup/restore the hashes instead of generating new hashes. QUESTIONS: 1. What is the format of the stored hash? Looks like concatenation of two [atypical] base64 fields. 2. How difficult would it be to remove the cleartext passwords from vpopmail? I see the logic of storing the "hint". But it means that for systems with multiple admins, all of the admins can view (and therefore use) most users' passwords. That is problematic even without considering the foreign intruder risk. My security concern for QMT has always been that I've never trusted the qmail accessories as much as qmail itself. I remain fairly confident that an intruder will not enter via port 25 (i.e. through qmail). But running the web server (for webmail) markedly increases the risk. QUESTION: could a webserver SQL-injection retrieve the cleartext passwords? -Andy On 10/2/2018 5: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 clear-text password, in the MySQL database. That > has already been established. What you probably don't know (or didn't think > of) is how those fields are used! > > Consider the following: > - First, the length of the hashing algorithm is a fixed length. Different > hashes, different lengths (for example: MD5 hashes are always 32 characters, > SHA1 hashes have 40 characters, sha512 hashes 128, and so on...) > - Second, ONLY the hashed password is used for validation. There is no NEED > for the cleartext password in the database, it's there simply because the > MySQL database was considered somewhat secure, and the original developers of > the QMT realized that about 40% of user problems are caused by NOT KNOWING > THEIR PASSWORDS, and being able to GIVE them their existing password was > generally easier than resetting it (and hearing complaints that, although you > "fixed" their desktop mail, now their phone's weren't getting email!) > - Finally, the original designers of QMT assumed people would use long > passwords -- it was suggested in the original documentation. Thus, saving > only the first 16 characters of the password in cleartext meant you were only > REALLY saving a "password hint" vs. the entire password. > > So - when you enter a 75 character password (only slightly absurd these > days), and if we assume a sha1 password hash, then the "set password" > function hashes your 75 characters into a 40-character SHA1 hash and saves it > into the database field that stores up to (magically) 40 characters. (FWIW: > when you enter your 2-character password of "ok", the sha1 algorithm ALSO > generates a 40 character output!). After is stores the hashed password, it > ALSO stores the first 16 characters of the cleartext password -- because > that's the length of the field in the database. > > When you try to authenticate, the password you provided is re-hashed > (regardless of its length -- although usually those fields have 64, 72, or > 128 character field limits - depending on the web-page designer/programmer), > and those 40 characters (the output of the sha1 hash) are compared to your > stored hash... there is no query of the cleartext password. > > Unfortunately, when you attempt to restore your passwords using just the > stored cleartext passwords, you will find (not surprisingly) that passwords > that were longer than the 16 chars generate a totally different hash result! > (Interesting side-note: you could have told your users that their passwords > were unchanged, but that they had to stop after the 16th character -- and it > would have worked!) > > I hope this explains a few things!! > > Dan > > > IT4SOHO, LLC > 33 4th St N; STE 211 > St. Petersburg, FL 33701 > +1-877-IT4SOHO > +1-877-484-7646 > For service requests, direct your email to serv...@it4soho.com > > > > -Original Message- > From: Eric Broch > Sent: Friday, September 28, 2018 1:35 AM > To: qmailtoaster-list@qmailtoaster.com > Subject: Re: Fwd: Re: [qmailtoaster] centos 6 > > Thanks, Andy. Plain text password have been a part of qt for as long as I've > been using it. I understand you're concern. I'm not sure about the password > length issue, I don't remember ever changing (patching) vpopmail like that, > but I'll look into it. > > > On 9/27/2018 11:28 PM, Andrew
Re: Fwd: Re: [qmailtoaster] centos 6
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 clear-text password, in the MySQL database. That has already been established. What you probably don't know (or didn't think of) is how those fields are used! Consider the following: - First, the length of the hashing algorithm is a fixed length. Different hashes, different lengths (for example: MD5 hashes are always 32 characters, SHA1 hashes have 40 characters, sha512 hashes 128, and so on...) - Second, ONLY the hashed password is used for validation. There is no NEED for the cleartext password in the database, it's there simply because the MySQL database was considered somewhat secure, and the original developers of the QMT realized that about 40% of user problems are caused by NOT KNOWING THEIR PASSWORDS, and being able to GIVE them their existing password was generally easier than resetting it (and hearing complaints that, although you "fixed" their desktop mail, now their phone's weren't getting email!) - Finally, the original designers of QMT assumed people would use long passwords -- it was suggested in the original documentation. Thus, saving only the first 16 characters of the password in cleartext meant you were only REALLY saving a "password hint" vs. the entire password. So - when you enter a 75 character password (only slightly absurd these days), and if we assume a sha1 password hash, then the "set password" function hashes your 75 characters into a 40-character SHA1 hash and saves it into the database field that stores up to (magically) 40 characters. (FWIW: when you enter your 2-character password of "ok", the sha1 algorithm ALSO generates a 40 character output!). After is stores the hashed password, it ALSO stores the first 16 characters of the cleartext password -- because that's the length of the field in the database. When you try to authenticate, the password you provided is re-hashed (regardless of its length -- although usually those fields have 64, 72, or 128 character field limits - depending on the web-page designer/programmer), and those 40 characters (the output of the sha1 hash) are compared to your stored hash... there is no query of the cleartext password. Unfortunately, when you attempt to restore your passwords using just the stored cleartext passwords, you will find (not surprisingly) that passwords that were longer than the 16 chars generate a totally different hash result! (Interesting side-note: you could have told your users that their passwords were unchanged, but that they had to stop after the 16th character -- and it would have worked!) I hope this explains a few things!! Dan IT4SOHO, LLC 33 4th St N; STE 211 St. Petersburg, FL 33701 +1-877-IT4SOHO +1-877-484-7646 For service requests, direct your email to serv...@it4soho.com -Original Message- From: Eric Broch Sent: Friday, September 28, 2018 1:35 AM To: qmailtoaster-list@qmailtoaster.com Subject: Re: Fwd: Re: [qmailtoaster] centos 6 Thanks, Andy. Plain text password have been a part of qt for as long as I've been using it. I understand you're concern. I'm not sure about the password length issue, I don't remember ever changing (patching) vpopmail like that, but I'll look into it. On 9/27/2018 11:28 PM, Andrew Swartz wrote: I recently did the backup/restore and I have one hiccup to report. A few of the account passwords did not work after backup from centos5 and restore to centos7. Took some time to troubleshoot, but I poked around in the vpopmail database and figured it out. It was due to the vpopmail database schema, which stores a 16 character password AND its hash. It allowed [and worked with] passwords longer than 16 characters (I'm unsure how). But after the backup/restore, all passwords longer than 16 characters failed. Problem was fixed by resetting all of these passwords to new ones with the proper length. Luckily there were not many like this. But for a large system, this could be a major pain. This seems like a bug. If the max password length is 16 characters, then the set-password webpage should reject passwords that are too long. Also, I'm not sure why it stores a plaintext password in addition to its hash. The modern standard is to store only the hash. This is potentially a major security problem. -Andy On 9/27/2018 8:57 PM, Tony White wrote: Eric, I now have a working v6 COS qmt, thank you for you help an patience. Now the backup and restore... best wishes Tony White On 28/09/18 14:43, Eric Broch wrote: changed now On 9/27/2018 10:41 PM, Tony White wrote: Eric, Yes I did run that command. At stage 3 after manually starting qmail at the end of qt-install. Stage 3 rpm -Uvh
RE: Fwd: Re: [qmailtoaster] centos 6
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 established. What you probably don't know (or didn't think of) is how those fields are used! Consider the following: - First, the length of the hashing algorithm is a fixed length. Different hashes, different lengths (for example: MD5 hashes are always 32 characters, SHA1 hashes have 40 characters, sha512 hashes 128, and so on...) - Second, ONLY the hashed password is used for validation. There is no NEED for the cleartext password in the database, it's there simply because the MySQL database was considered somewhat secure, and the original developers of the QMT realized that about 40% of user problems are caused by NOT KNOWING THEIR PASSWORDS, and being able to GIVE them their existing password was generally easier than resetting it (and hearing complaints that, although you "fixed" their desktop mail, now their phone's weren't getting email!) - Finally, the original designers of QMT assumed people would use long passwords -- it was suggested in the original documentation. Thus, saving only the first 16 characters of the password in cleartext meant you were only REALLY saving a "password hint" vs. the entire password. So - when you enter a 75 character password (only slightly absurd these days), and if we assume a sha1 password hash, then the "set password" function hashes your 75 characters into a 40-character SHA1 hash and saves it into the database field that stores up to (magically) 40 characters. (FWIW: when you enter your 2-character password of "ok", the sha1 algorithm ALSO generates a 40 character output!). After is stores the hashed password, it ALSO stores the first 16 characters of the cleartext password -- because that's the length of the field in the database. When you try to authenticate, the password you provided is re-hashed (regardless of its length -- although usually those fields have 64, 72, or 128 character field limits - depending on the web-page designer/programmer), and those 40 characters (the output of the sha1 hash) are compared to your stored hash... there is no query of the cleartext password. Unfortunately, when you attempt to restore your passwords using just the stored cleartext passwords, you will find (not surprisingly) that passwords that were longer than the 16 chars generate a totally different hash result! (Interesting side-note: you could have told your users that their passwords were unchanged, but that they had to stop after the 16th character -- and it would have worked!) I hope this explains a few things!! Dan IT4SOHO, LLC 33 4th St N; STE 211 St. Petersburg, FL 33701 +1-877-IT4SOHO +1-877-484-7646 For service requests, direct your email to serv...@it4soho.com -Original Message- From: Eric Broch Sent: Friday, September 28, 2018 1:35 AM To: qmailtoaster-list@qmailtoaster.com Subject: Re: Fwd: Re: [qmailtoaster] centos 6 Thanks, Andy. Plain text password have been a part of qt for as long as I've been using it. I understand you're concern. I'm not sure about the password length issue, I don't remember ever changing (patching) vpopmail like that, but I'll look into it. On 9/27/2018 11:28 PM, Andrew Swartz wrote: > I recently did the backup/restore and I have one hiccup to report. > > A few of the account passwords did not work after backup from centos5 > and restore to centos7. > > Took some time to troubleshoot, but I poked around in the vpopmail > database and figured it out. It was due to the vpopmail database > schema, which stores a 16 character password AND its hash. It allowed > [and worked with] passwords longer than 16 characters (I'm unsure how). > But after the backup/restore, all passwords longer than 16 characters > failed. Problem was fixed by resetting all of these passwords to new > ones with the proper length. Luckily there were not many like this. > But for a large system, this could be a major pain. > > This seems like a bug. If the max password length is 16 characters, > then the set-password webpage should reject passwords that are too long. > > Also, I'm not sure why it stores a plaintext password in addition to > its hash. The modern standard is to store only the hash. This is > potentially a major security problem. > > -Andy > > > On 9/27/2018 8:57 PM, Tony White wrote: >> Eric, >>I now have a working v6 COS qmt, thank you for you help an patience. >> Now the backup and restore... >> >> best wishes >>Tony White >> >> On 28/09/18 14:43, Eric Broch wrote: >> >>> changed now >>> >>> >>> On 9/27/2018 10:41 PM, Tony White wrote: Eric, Yes I did run that command. At stage 3 after manually starting qmail at the end of qt-install. Stage 3 rpm -Uvh
