Reacts Security Overview


1. Connection Encryption

Encryption Requirements

All external access points to the Reacts APIs and services require secure connections using Transport Layer Security (TLS). All internal access points between Reacts services require secure connections using industry standards encryption methods.

Ports and Protocols
Website / Service Port Protocol 443 TLS 1.2 443 TLS 1.2 443 TLS 1.2 443 TLS 1.2 443 DTLS-SRTP 443 DTLS-SRTP

Denied Ciphers and Protocols

Explicitly blocked protocols: SSL 2, SSL 3, TLS 1.0, TLS 1.1
Explicitly blocked ciphers: 3DES, RC2, RC4 and DES56

2. Video, voice and text exchange encryption

Audio/video communications are established via WebRTC and utilize the DTLS-SRTP security context to encrypt and decrypt streams from end to end.

The signaling channels are completely separated from the media transport and are TLS secured. The certificate fingerprints are sent through this secure connection, reducing the possibility of MITM attacks. Every connection and session use unique keys.

For environments where Peer to Peer (“P2P”) connections are not possible due to infrastructure and firewall restrictions, IIT provides access to its hosted TURN services. TURN acts as a relay service to connect parties together in places where only outbound connections are allowed. The DTLS-SRTP allows secure end to end protected sessions over either UDP or TCP. Given that UDP provides higher performance and lower bandwidth requirements, it is the preferred alternative.

Text messaging is always transmitted via the signaling service and is thus secured with TLS.

IIT’s implementation of WebRTC prioritizes audio/video stream connections as follows:

1. P2P UDP;
2. P2P TCP;

Therefore, if an institution’s firewall allows P2P via UPD and/or P2P via TCP, the stream connection will be established in P2P. If an institution’s firewall blocks P2P connections, the stream will be established via TURN UDP or TCP with TLS encryption.

3. Two-factor authentication and robust password

Reacts allows the use of two-factor authentication. The current implementation uses the principles of “Something you know” and “Something you have”. 

  • Something you know: Username and password. The password is expected to remain confidential
    and hard to guess.
  • Something you have: IIT uses a TOTP standard algorithm implementation of “Something you

There are many free applications that can be used to calculate a token based on a secret the user stores in his/her device. The token is required if the user configures his/her Reacts account for two-factor authentication.

The two-factor authentication reduces enormously the chances of success of many types of exploits. Just to mention the most common ones, social engineering, brute force and dictionary attacks become extremely hard to succeed when a two-factor authentication is enabled. In the case a malicious individual gets access to a password, the “thing you know”, it will be very difficult for such person to produce the right token, “something you have”. In the contrary case, if the malicious user gets access to the device using “something you have”, it will still be needed to figure out the “something you know” factor.

Upon registration, the user must provide the following security information:

  • An email address;
  • A robust password (8 characters minimum, including one upper-case, one lower-case and one
  • When a user will have chosen the two-factor authentication, it will also be needed to register
    Reacts in an application that can generate the TOTP tokens his/her device.

In order to access Reacts for the first time, the user will receive an activation key via email or
text message, allowing him/her to validate the ownership of the e-mail account.

4. Data at rest security

  • The database and database backups are encrypted at rest using “Transparent Data
    Encryption” (TDE) with AES 256 block mode encryption.
  • The servers used for storage are located in a sub-network that is not exposed to the internet. Only
    the computers and the Reacts services that require it as well as a restricted group of users have
    access to this network.
  • The stored user files are encrypted using AES 256 block mode encryption. The symmetrical keys
    used to decrypt the data are stored separately in the database server. These keys are never
    exposed to human users and are only made available to the services that provide access to these
    files as per the authorized owner requests.
  • Each file is encrypted using its own key and different Initialization Vectors (IV) (e.g. two files
    belonging to the same user are encrypted using two different keys).
  • Access to encrypted information by IIT or IIT suppliers is strictly prohibited by security and
    access policies as well as by implemented security mechanisms.
  • Access to the storage servers is strictly regulated by IIT’s internal policies and service

5. Local storage encryption

Client device security is mostly the responsibility of the owner of the device. However, Reacts implements a few measures to reduce the risk even on the client-owned devices.

On Windows-Based Devices
  • Reacts creates a folder that will host a virtual drive where the user’s Reacts data is stored with encryption.
  • The local user data is encrypted with the Salsa20 encryption algorithm using symmetric keys.
  • The keys are stored in the user’s Windows vault.
  • The data is encrypted at rest. Once the user is connected to Reacts, the data is accessible upon request.
  • When Reacts is not running, the virtual drive’s data is only accessible in encrypted form and therefore illegible.

On iOS (Apple) Devices

Reacts counts on the encrypted iOS sandbox to protect Reacts data at rest and from other

On Android Devices

Reacts ensures that the device encryption is enabled before allowing to store data in the device.

On Web Browsers

Reacts does not allow caching of files in the browser, preventing them to stay at rest. Session and
authentication cookies are stored with encryption.

6. High availability (HA) and disaster recovery

The Reacts platform infrastructure is designed with high availability (HA) and disaster recovery
(DR) in mind.

High Availability Measures

All virtual machines are deployed within Azure Availability Sets with two instances or more. Isolated fault domains of Availability Sets provide high availability and resiliency against local failures, such as connectivity and power outages.

Disaster Recovery Measures

Virtual machines and other cloud resources are hosted in two different Microsoft Azure regions:

1. Canada East – Primary region;
2. Canada Central – Secondary region.

Both the primary and secondary Azure regions contain a fully functional copy of the Reacts
platform infrastructure.

Replication between regions is done automatically without any required human intervention.

In case of regional failure, disaster recovery mechanisms are handled by Azure Site Recovery, which is configured for automatic failover to the Canada Central region.

Azure Storage Accounts are configured with geo-redundant storage across the Canada East and Canada Central regions.

Disaster Recovery Objectives

Recovery point objective (RPO) is targeted at 60 seconds or less.
Recovery time objective (RTO) is targeted at 2 hours or less.

Regional Isolation

The primary and secondary Azure regions are currently physically separated by over 700 kilometers.

7. Data backups

3-Level Data Backup System

1. Active online backup: 0 data loss – IIT’s primary database is actively replicated to a secondary server via a high-availability database cluster.

2. Passive online backup: +/- 1 hour of potential data loss – IIT performs passive backups on the primary database server. These backups don’t automatically overwrite, allowing IIT to minimize data loss in case of corruption. The database backup files are stored on a secure and georedundant Azure storage account.

3. Persistent daily backups are performed on all virtual machine disks, and provide an extra layer of protection. They are stored to an Azure Recovery Services Vault following IIT’s retention policies.

Backup Encryption

Encrypted data remains encrypted when backed up and is subject to IIT’s security and remote
access policies.

8. Audit logs

Reacts logs operations performed by users. These logs contain the following information:

  • Date and time for each type of operation;
  • Type of operation;
  • Connection success;
  • Connection failure;
  • Session request;
  • Session accepted;
  • Session aborted;
  • Document shared;
    Password reset;
  • Password changed;
  • Requester (user identifier);
  • Message (description of operation type);
  • Room ID (identifier of a session between users);
  • Additional fields (other fields helping to read the log entry).

Log data is available upon request of the owner of the account.

9. Independent audits

Innovative Imaging Technologies (IIT) is dedicated to upholding its security and confidentiality
policies as well as the higher standards of quality for its solution.

In addition, IIT is committed to undergoing an annual IT pentesting of its Reacts solution by a
specialized external firm (“Hitachi Systems Security”), in order to ensure that the quality and
security of the Reacts platform as well as the IT network are maintained.

10. Data flow map

11. Single sign-on (SSO)

IIT uses the OAuth2 standard and the OpenId Connect protocol to establish a trust relationship between the partner system and Reacts platform. This trust allows the user to transition from the partner system to Reacts platform without having to re-authenticate (single sign-on).

12. Hosting

IIT’s servers are hosted in a localized instance of Microsoft Azure Cloud Services.

  • Primary instance resides in Azure’s Canada East Region.
  • Secondary instance resides in Azure’s Canada Central Region.