Platform security

Owned by Sebastian Arena
Last updated: Mar 14, 2024
7 min read

Provider information

Name
Chat-Tonic

Developer
Chat-Tonic (MINIATURE SRL for US and Latin America, Chat-Tonic OÜ for the rest of the world)

Licensing
Closed Source / Software-as-a-Service (SaaS)

Technology
The platform is developed entirely in Javascript: Node.js / React.js We use as databases: MongoDB and Redis

Data storage

Chat-Tonic strikes a balance between the data that you want to protect, and those that are necessary for the bot to be used correctly (for example, sometimes it is better for the bot to remember a person's email, than to ask them constantly every time it is needs to use it).

Typically a record is kept in our database of the conversations and conversation history with each person the bot spokes to. Storing conversation data and metadata is completely optional and can be turned off if necessary or wanted.

Normally maintaining a certain level of data learned in a conversation is useful to give a better response. At the request of the client, the data of the conversations can be deleted from our platform. In addition to the data to have a better experience, it is possible that you want to save or delete the conversation history, for which we also have an optionally configurable policy. Check with your assigned project leader and developer with options on how to setup your specific preference.

Chat-Tonic as a platform is the tip of a series of providers that also have access to the same information that the platform receives (except in the case of exclusively using Web Chat-Tonic, in which case the provider of the final bot experience is also ourselves, and we manage the solution end-to-end). If you want to use Facebook Messenger or WhatsApp, the restrictions that these platforms apply to us limit what we can use as information, and at the same time know that the data already flows through these systems that could generate their own records.

In the access dashboard, conversations can be anonymized so that administrators who access it do not see any relevant user data (Name, Surname, Telephone). This is useful to provide access to customize the bot and view reports, but not let any client user see user data that they should not see.

The platform safeguards the contents and interactions of the chatbot with end users in various locations, depending on the type of data:

The platform core handles the following sets of data:

  • Conversations and messages

  • Admin Users

  • Chatbot setup, AI, and the entirety of the chatbot experience

Data can be stored in the European Union (Frankfurt, Germany) or the United States (Dallas, Texas), depending on the client's decision at the time of the initial implementation of the chatbot. The data is stored mainly on Chat-Tonic servers in the cloud, provided in VPS format by Linode. Additionally, the reporting, statistics and metrics system is stored in Google Big Query, in the same region as the data stored in the core of the system.

VPS geographic region:

  • Clients in LATAM and USA: Dallas, Texas, USA

  • Clients in EU: Frankfurt, Germany

BigQuery geographic region:

 

Additionally, customers could enable the human derivation module, known internally as Customer Service, where the bot connects to a live human agent for specific interactions.

Customer Service handles the following sets of data:

  • Queries started from the chatbot, that are in term handled by the human live agent. We store when the query started, which operator handled it, and the internal state of it through its lifecycle. The messages are stored in the core module with the rules explained before.

  • Query origins

  • Query resolutions

  • Human Live Agent Knowledge Base

  • Human Live Agent Users and Coordinators

Data can be stored currently only in the European Union (Frankfurt, Germany). The data is stored mainly on Chat-Tonic servers in the cloud, provided in VPS format by Linode. Additionally, the reporting, statistics and metrics system is stored in Google Big Query, in the same region as the data stored in the core of the system.

VPS geographic region:

  • Clients in LATAM, USA and EU: Frankfurt, Germany

BigQuery geographic region:

Finally, clients could enabled our Web Chat-Tonic module to be able to embed their chatbot on their own websites and portals.

Web Chat-Tonic handles the following sets of data:

  • Conversations and messages received or sent solely through this module

Data can be stored in the European Union (Frankfurt, Germany) or the United States (Dallas, Texas), depending on the client's decision at the time of the initial implementation of the chatbot. The data is stored mainly on Chat-Tonic servers in the cloud, provided in VPS format by Linode. Additionally, the reporting, statistics and metrics system is stored in Google Big Query, in the same region as the data stored in the core of the system.

VPS geographic region:

  • Clients in LATAM and USA: Dallas, Texas, USA

  • Clients in EU: Frankfurt, Germany

BigQuery geographic region:

Data security

Conversations and messages that Chat-Tonic receives or sends is done typically through public chat platforms, such as WhatsApp, Facebook Messenger, Instagram, Telegram, and additionally its own private Web Chat-Tonic platform. In all cases of public platforms, the maximum security of the data is given by what each of these platforms offers. That is, any vulnerability, data leak, or improper storage of information will be their responsibility.

Having clarified the previous point, it is important to note that all exchange of conversations and messages with chatbot platforms is carried out via secure HTTPS protocol EXCLUSIVELY to protect data in transit.

Chat-Tonic does not encrypt the data stored in databases at rest.

Chat-Tonic does not encrypt the backups of data stored in the databases, and protects full backups of all your data for 30 days, obtained on a daily basis.

The user authentication information is the only one encrypted in the system as detailed in the point under "User authentication”.

Chat-Tonic typically does not store sensitive user information such as Name, Surname, Email, ID, unless the chatbot needs it for its normal operation (and it has been validated with the Client), for lead generation or integrations with the client or third party APIs. In any case, there are several mechanisms that are available to the client to mitigate any problem or need for data privacy:

  1. The data stored by the chatbot can be deleted by it after a time determined by the client, which can be seconds, up to days. It is important that the correct functioning of the chatbot is allowed with this data, and then it is deleted if required.

  2. The conversation history could be used to infer user data. The customer can choose to have Chat-Tonic delete this information after a certain number of hours. It is important to be able to keep the history for at least 24 hours if the Customer Service module is enabled, so that human agents can have the proper context to resolve the query. After that time the information can be deleted.

  3. The system's inactive conversations are considered such after 90 days of not having communication with the chatbot (although this can be configured to be anything from 1 day to 1 year), they are eliminated from the database and stored in a separate repository indefinitely (which can also be turned off if no recollection of past conversations needs to happen).

  4. Leads and Checkpoints can be subject to the same configuration explained in point 3, for their archiving and expiration.

User authentication

Does the application employ user / password based authentication?
Yes

What authentication mechanisms and Single SignOn are supported?
None. (Estimated implementation date: second half of 2021)

Does the application allow users to change their passwords?
Yes.

Password Management

  • Minimum length setting.

  • Repository of users and passwords encrypted with standard non-reversible algorithms.

Password Storage
Using a dedicated password-based key derivation function: bcrypt (https://en.wikipedia.org/wiki/Bcrypt)

Setting the initial password
The initial password or a link to set it is sent to users by email.

When the user receives their initial password, will their account be pre-populated with any confidential information?
Yes, when users log in for the first time, the confidential information is already visible.

Account Recovery
A link to reset the password is sent by email to the user's registered address.

User roles

There are 3 pre-defined roles: Administrator, Supervisor and Operator. Since most of the users are usually Operators, to be able to solve queries generated from the chatbot and then derived to a human. It is not possible to define new roles.

Defining users and credentials
There is a CRUD Users module.
You can change roles to users.
There is and option to disable users manually.

The application protects state change actions against cross-site request forgery (XSRF https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)))
All state change actions are protected. There is a way to ensure that no action falls outside of this protection (such as forcing XSRF token checks at a central site).

What strategy does the application use to protect against XSRF?
The application does one of the following: checks the referrer header; requires that all actions that change state are POST requests; employs another mechanism to protect against XSRF.

Many web applications use AJAX for background data exchange
The application uses another format that sets variables or function calls with non-public information.

The application can be affected by XSSI, unless it is specifically protected against this type of attack.
The application uses a back-end database, or any other back-end persistence that can be queried via SQL or with a related language (for example, GQL, FQL, SOQL, etc.).

Select the mechanisms for the construction of session identifiers (Session IDs) that the application uses:
There is no Session ID, simply a JWT with finite expiration time is handled

Does the application offer a "log out" button or link that, when clicked, not only terminates the session (clears the client's cookies), but also invalidates all session identifiers?

Yes

Handling of vulnerability reports

Is there an easily visible way for clients, users and external researchers to report security vulnerabilities in the application?
No, we do not offer a way to report security problems about the application

Penetration Tests
Not performed at the moment

Vulnerabilities check
Performed 24/7 and alerted via our Datadog monitoring system

Encryption, HTTPS and Content
The web application is accessible exclusively through HTTPS. Even if the user manually edits the URL to start with http: //, it won't work or it will redirect to https: //.

Have you recently reviewed your SSL settings to ensure that only secure encryption and protocols are offered to users?
Yes, we regularly review the encryption and protocols used.

Does your server offer forward secrecy (https://en.wikipedia.org/wiki/Forward_secrecy) for clients that support it?
Yes, the server supports ECDHE and DHE ciphers that offer forward secrecy.

Are your SSL / TLS private keys adequately protected on your web server?
Yes, we have taken all necessary measures to protect our private keys.

Where does the SSL connection between the user and the application terminate?
On the application server.

Have you deployed HTTP Strict Transport Security (HSTS - https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security) on your server?
Yes we use HTTP Strict Transport Security

If your application supports authentication, are authentication cookies marked with the secure attribute?
No.