API /users.info does not return bcrypt password anymore

[sistason]

Description:

When querying the users.info API endpoint as Admin user (with view-full-user-info permission active), I get an empty list of services. In the mongoDB, I see the bcrypt hash and resume loginTokens, which are not returned by the API. This was possible at least in 3.0.3 and we based our whole infrastructure SSO on syncing user passwords from Rocketchat to other services (it just has the superior user data change UI).

Steps to reproduce:

1. Call the (/api/v1/users.info?username=XXX) as admin user
2. the response is missing the services
3. the user HAS a password and it's available in the mongoDB backend

Expected behavior:

Be able to query the bcrypt hash as admin user via the API

Actual behavior:

• /api/v1/users.info?username=XXX

  {'user': {'_id': 'ID',
  'createdAt': 'SomeDateZ',
  'services': {},
  'username': 'XXX',
  [...]
  }

• db.users.find({username: "XXX"}).pretty()

  {
  "_id" : "ID",
  "createdAt" : ISODate("SomeDateZ"),
  "services" : {
      "password" : {
          "bcrypt" : "$2b$10$..........."
      },
      "resume" : {
          "loginTokens" : [ ]
      }
  },
  "username" : "XXX",
  [...]
  }

  Server Setup Information:

• Version of Rocket.Chat Server: 3.5.3

• Operating System: ubuntu

• Deployment Method: docker

• Number of Running Instances: 1

• DB Replicaset Oplog: Enabled

• NodeJS Version: 12.16.1

• MongoDB Version: 4.0

Client Setup Information

• Desktop App or Browser Version: API
• Operating System: ubuntu

Additional context

Did work in 3.0.3

Relevant logs:

Rocketchat DEBUG log shows the same:

I20200823-19:20:06.825(0) API ➔ debug Success {   statusCode: 200,   body: {     user: {       _id: 'ID',       createdAt: DateZ,       services: {},       username: 'XXX',       emails: [Array],       type: 'user',       status: 'offline',       active: true,       roles: [Array],       name: 'XXX',       statusText: '',       lastLogin: DATEZ,       statusConnection: 'offline',       utcOffset: 2     },     success: true   } } 

[FelipeParreira]

Hi, @sistason! Thank you for the issue 👍

For security reasons, we have decided not to send the bcrypt password anymore as a response to this endpoint as of version 3.2.0.

The PR that addressed this issue is here.

If you could give us more info about how your SSO worked, maybe we can try to help you find a workaround for this issue.

[FelipeParreira]

@sistason, what you seem to be doing is actually not recommended.

Here are some alternatives:

1) You can use SSO via iframe, in order to authenticate in Rocket.Chat using/validating credentials from another system (if OAuth is not an option);

2) Or you can create an OAuth Server in Rocket chat (so that you can log into other systems through Rocket chat).

Let us know if you want us to go deeper into any of theses options.

[sistason]

@sistason, what you seem to be doing is actually not recommended.

Story of my life ;)

You misunderstand my intentions as to login TO rocketchat. I try to authenticate other services against rocketchat's users. I.e. Nextcloud only wants to be an OAuth Server, and its generic oauth implementation cannot really do generic servers like Rocketchat. So I'm stuck authenticating Nextcloud against SAML/LDAP. These need to be "seeded" from the user-data of rocketchat and synced. I wrote https://github.com/sistason/rocketchat_ldap_sync to query the RC users.info API to get uid+passwords.

Using the API is nice, because the script can run on the LDAP host so I don't need the LDAP-server to be available to the internet. Without the API, I can only get the password-hashes from mongodb directly, so the script has to run on the rocketchat-server, using ldapmodify to input the data.

TL;DR: If services don't want to auth against Rocketchat, you have to carry the auth to something they want to auth against ;)

[FelipeParreira]

We were sorry, but we don't plan to add this functionality again, as it would cause some serious security issues for RocketChat.

We think some of the options given above might be what is most appropriate for you, even if it may require some re-work on your part.