11 April 2010, 19:56

Recently we experienced some problem with LDAP connection (LDAP Server issues). Due to what users were not able to log into Mahara.

Now, in this case Mahara was not able to connect LDAP server and was dumping the call stack in error log. It also dumps the username (normal) and password (strange !).

[Mon Apr 12 09:17:05 2010] [error] [client X.Y.Z.A]   * AuthLdap->authenticate_user_account(object(stdClass), "MyPassWord") at /var/eport/auth/user.php:857, referer: http://eport-dev

[Mon Apr 12 09:17:05 2010] [error] [client X.Y.Z.A]   * LiveUser->login("yajumahida", "MyPassWord") at /var/eport/auth/lib.php:1144, referer: http://eport-dev

11 April 2010, 21:47

I would have thought that anyone who could see the log would have access to log in as anyone anyway? 

Logs contain detailed information about problems, that's the point of them. The only people who should be looking at them should be the system administrators, really.

11 April 2010, 22:43

But this is strange. Passwords shouldn't be there. Not useful and also not a good practice. Why even system administrator should know the passwords ?

11 April 2010, 23:42

I don't know where it says that passwords being in the logs is bad practice, but what I can say as a developer is that it's pretty damn hard to keep them out!

The problem is, the password is in the backtrace when an error is occuring. A backtrace is just a set of filenames, line numbers, method/function names and arguments. There's no clue in it to suggest what data is a password or not. So it's all but impossible to "filter" them out, because we don't know where they are.

Furthermore, a developer might not want to filter them out - they might actually want or need to see the password for some reason (e.g. to check that the password wasn't mistakenly changed by the application somewhere else).

Given that, I can't see how you can somehow keep them out of the logs. And given that logs hold other detailed information about the system, I think your better bet is to restrict who can view them to administrators, and rely on your standard policies that prevent employees abusing such information