getUserSession stores passwords

[jswlinux]

I've developed my simple owncloud app, and did this print_r(OC_User::getUserSession()); due to some reason. I found two passwords.

Expected behavior:
The array would have needed information except an user's password.

Actual behavior:
Two passwords for a LDAP Bind and a current user were found.

Steps to reproduce
print_r(OC_User::getUserSession());

Server configuration:
OS: Ubuntu 12.04 64bit
Web server: Apache 2.2.22-1
Database: PostgreSQL 9.1
PHP v5.3.10-1
ownCloud 6 Enterprise Edition 6.0.1 Testing
Fresh installed

List of activated apps:
Activities
Deleted files
Export/import
Export/import for users
External storage support
First Run Wizard
Full Text Search
LDAP user and group backend
Share Files
Text Editor
Versions
WebDAV user backend

Client:
Chrome on Ubuntu 12.04 64bit

[karlitschek]

@blizzz Any idea?

[DeepDiver1975]

FYI: our irods external fs implementation is storing the user password in the session as well

[blizzz]

The LDAP backend does not store them in the session, must happens somewhere else.

[blizzz]

Alright, so what I see is that it prints the OC\User\Session instance.
It also holds the backend instances, i.e. all it's properties are shown as well.
The password with regard to LDAP that you see is that one for the bind user, required to accomplish the LDAP bind. No user password is kept.

It is not the PHP session.

[sfabel]

We can see the admin password in addition to the BIND PW.

[blizzz]

Which admin password? Local user, LDAP user?

[sfabel]

Sorry, the local admin user (which was the user logged on at the moment).

[blizzz]

I do not see the password of my (also local) user. We do not store it permanently anyway, it is used however for the login, obviously. For the login and attached processes (e.g. in encryption) the password is necessary i.e. it needs to be available in this time. Maybe there is a chance to clean this up, but it does not change anything about the fact that it needs to be processed on the login action. In other corner cases, as @DeepDiver1975 stated for IRODS the password must be kept since it needs to be passed on. Same is true for the LDAP Bind Password.

[sfabel]

Plaintext is pretty scary... If there's a way to avoid caching this (isn't this what a session is supposed to be?) Please change this. BIND user is understandable and no big deal. We will post output from what we see -I'll let my colleague know.

[jswlinux]

Please see attached screenshot.

I blocked some sensitive info with yellow colored boxes. The blue colored is the BIND user's password, which is not a big deal. The red one is MY LDAP ACCOUNT PASSWORD.

[sfabel]

Maybe we can modify this request (if irods requires it) to: don't store irods credentials if you don't have that external storage configured?

[jnfrmarks]

@LukasReschke

Should this issue be closed? I validated this fix along with PR 11747.

[LukasReschke]

Once #12523 is merged.

[LukasReschke]

Will be fixed with 7.0.4