SPIKE: Riff-Server API Credentials can be Intercepted.

[jaedoucette]

The authentication process used by riffplatform & RiffEDU, in both our testing and production environments appears to leak credentials to any user smart enough to check for them.

After obtaining these credentials, a malicious user could perform arbitrary operations on any Riff-server instance that uses the same credentials. For example, they could retrieve a list of all users, and delete them one by one from the system. Or they could add arbitrary data to any table (e.g. fake utterances, fake users, fake meetings).

Steps to Reproduce

Riffplatform:

1. Navigate to an instance of riffplatform.com.
2. Open developer tools in Chrome.
3. Navigate to the sources tab.
4. Insert a breakpoint at line 62 of redux/actions/riff.js
5. Refresh the page.
6. Inspect the environment variable 'email' and 'password'.

RiffEDU:

1. Open a link to a Riff Meeting.
2. Open developer tools in Chrome.
3. Navigate to the sources tab.
4. Navigate to webpack/./action/views/riff.js
5. View the hard-coded email and password variables on line 66.

Expected behavior

1. Riff should not use the same username and password to authenticate every user to the API of our database.
2. Riff should not use an easily guessed username and password for important authentications.
3. Riff should limit the actions that users can perform against the database. For example, a user should not be able to delete records belonging to another user. Possibly no users at all should able to delete records because if we need to delete records, we can log in to the docker instance running MongoDB, and manually alter that database (e.g. during a rollback).

Possible Solutions

1. Refactor Riff-server, and in the course of that work, migrate to a much more secure API.
2. Patch the existing API by having each user authenticate separately. Replace API calls that delete information with new calls that delete only information belonging to the current user (or remove all deletion functionality, but this might involve a much large overhaul).

Acceptance Criteria

The most critical API changes to patch the main security risk have been completed and are documented in story #251.

Spike Acceptance Criteria

• [ ] A written summary and scope of work for one or more options to accomplish the following: Restrict access control to the data so that queries can only retrieve data to which they should have access - which is meetings that they have attended.

The goal of this spike it to have enough information to know how to prioritize the proposed solution(s), based on their complexity, size and benefit of the work.

Context

New Security Issues.

Site the bug occurred on:

All tested environments.

Desktop (please complete the following information):

Tested with Chrome.

[jaedoucette]

We are able to get a complete, unencrypted list of everyone in a production database, without even signing up for an account.

Therefore, this but is a high priority security issue, because our clients want that data to be encrypted.

[jaedoucette]

Possible solution: have riff-server authenticate against our firebase server or LTI.