Kloxo

PLease write all the exact lines in the logs with clear text passwords.
That is easier finding in the source files. (its somewhere in log_log("shell_exec", ....)

Please provide examples. I am waiting for it...

In one shell window:

/script/fixmail

In another:

[root@serv24 ~]# tail /usr/local/lxlabs/kloxo/log/shell_exec
(...)
01:14 Sep/06/2010: 0:  [(__system__:/usr/local/lxlabs/kloxo/httpdocs) '/home/lxadmin/mail/bin/vpasswd'  'postmaster@serv24.zanhost.com' 'PASSWORD']
(...)

Note the part where it says "[(system:/usr/local/lxlabs/kloxo/httpdocs) '/home/lxadmin/mail/bin/vpasswd' 'postmaster@serv24.zanhost.com' 'PASSWORD']"

I replaced the actual password (that was written to the log) with PASSWORD.

Passwords should not be stored as plain text in the first place.
From what I see in my production server, the accounts which have a modified password store it as plain-text in vpopmail table, field pw_clear_passwd. The passwords initially entered in the add form are not stored in plain text, but left left empty.

Is there a reason to store the generated password in plain text ?

Lucian Sabo wrote:

Passwords should not be stored as plain text in the first place. From what I see in my production server, the accounts which have a custom password don't store it as plain-text, but the passwords generated by kloxo are stored in plain text in vpopmail table, field pw_clear_passwd

Is there a reason to store the generated password in plain text ?

The passwords don't need to be stored in plain text, but they do need to be stored for some things. I'm not certain we need to store passwords for mail, but there are some things we must store passwords for.

An example being vpopmail. vpopmail stores its own passwords, and those are stored inside the vpopmail database. We can't just change that because I'm not sure why it stores the passwords in plain text. We need to investigate and then figure out what we should do.

but there are some things we must store passwords for.
Such as ?

In database kloxo, table mailaccount, the password is stored encrypted in field pasword.
There is another field for which I don't know it's use named realpass, but the values is not in plain text either.

So the only place where we have plain-text password is in the vpopmail database, table vpopmail.

vpopmail stores its own passwords, and those are stored inside the vpopmail database. We can't just change that because I'm not sure why it stores the passwords in plain text

If the passwords are stored in plain text only for the passwords updated by user, and for the rest which are entered initially, the plain text password is empty, we may say that this field is not needed since it works fine without a value.

After some investigations I found out the reason for this clearpasswd field and what can break if left blank.

According to this message on the qmailtoaster list
http://www.mail-archive.com/vchkpw@inter7.com/msg27379.html

this will break the CRAM-MD5 authentication method. Both client and server need to know the password for CRAM- MD5 to work properly. If you do this, it's likely that qmail will still claim it supports CRAM-MD5, but if a client tries to authenticate using this method it will fail.

Another message says:

Thurderbird use CRAM-MD5 auth first if it fail then use PLAIN auth but for Email Client on Nokia phones seem use CRAM-MD5 only it wont try Auth Plain

So, we have two choices: Put plain text password for all records, or don't use CRAM-MD5 by rebuilding vpopmail with --disable-clear-passwd.
Now we have an inconsistency - vpopmail will report it supports CRAM-MD5, but the login will fail with some users, which don't have plain text passwords in their table records.

I think it worths the trade-off of supporting a more secure authentication like CRAM-MD5 versus not having plain text passwords in one table, but communicating with plain passwords on the protocol.

We need to check out also the password of user lxpopuser to enforce security on database if we store plain text passwords.

About this issue - we can simply remove read permissions from everyone on log files (chmod 660 or 640).