Password logging

[martin.bek]

Seriusly… Are you kiddin’ me???

PHP message: #0 /usr/share/egroupware/vendor/adldap2/adldap2/src/adLDAP.php(653): adLDAP->connect()
PHP message: #1 /usr/share/egroupware/api/src/Accounts/Ads.php(1277): adLDAP->__construct(Array)
PHP message: #2 /usr/share/egroupware/api/src/Accounts/Ads.php(172): EGroupware\Api\Accounts\adLDAP->__construct(Array)
PHP message: #3 /usr/share/egroupware/api/src/Auth/Ads.php(51): EGroupware\Api\Accounts\Ads::get_adldap()
PHP message: #4 /usr/share/egroupware/api/src/Auth.php(230): EGroupware\Api\Auth\Ads->authenticate(‘martin.bek’, ‘MySecretPasswor…’, NULL)
PHP message: #5 /usr/share/egroupware/api/src/Session.php(517): EGroupware\Api\Auth->authenticate(‘martin.bek’, ‘MySecretPasswor….’, ‘text’)
PHP message: #6 /usr/share/egroupware/login.php(251): EGroupware\Api\Session->create(‘martin.bek@defa…’, ‘MySecretPasswor…’, ‘text’, false, true, true, ‘’, NULL)

Note: Latest Egroupware Community, incorrectly bound to AD.

[StefanU]

Seriusly… Are you kiddin’ me???

You talk to all the people like that?
Then you don’t need to hope that anyone talks to you. Do that again and I’ll lock you!

suppress warning and trace (containing passwords) if userPassword attribute is not accessible

Stefan

[RalfBecker]

Not part of my above mentioned commit. That was LDAP with password migration enabled and no access to passwords, was logging every password when a user is authenticating (successful).

I see this one less serious, as it only happens if you have a wrong IP or password for the AD set, not regular on an otherwise fully working system. Silencing that makes it hard to diagnose why anything is not working.

Ralf

[martin.bek]

OK, I admin I got bit emotional, sorry.
I understand that in some cases password logging can be helpful but i really should NOT be default setting! It’s HUGE security threat!
Since there is no warning it’s very likely that admins will not delete logs after initial settings.
Maybe I did not read your documentation enough but I really did not see warning about this. And I was really surprised (in a bad way).

@RalfBecker: I can easily imagine situation like this:

• Fresh install
• Setup AD bind but with minor mistake
• Mistake fixed without log investigation
• Admin does not know about logging passwords in plain text so he does not delete logs
  And logs stays there for god knows how long. And if sever is hacked you have wide open doors everywhere.

Another example (my situation):

• Fresh install
• AD setup with some problem
• Admin does not see the problem and ask collegues for help
• Whole office knows admin’s password

Storing any password in plain text really should be forbidden by default everywhere. If you want this option it should be enabled by user.

[RalfBecker]

I understand that in some cases password logging can be helpful but i really should NOT be default setting!

We are NOT doing password logging!

We log connection errors to the AD server, which is NOT enabled by default, but a configuration you created.

The log contains a trace with arguments, that is a standard feature of PHP. Only alternative is to fully suppress these connection errors and only log a general connection error, like we display it in the frontend.

Storing any password in plain text really should be forbidden by default everywhere. If you want this option it should be enabled by user.

If you want to talk to an other service, you can NOT store a hashed password! You need the password available to talk to that service.

In general logs are send to the docker daemon and get rotated (and therefore deleted) by it.

Ralf