Last Updated: October 24th, 2019 to reflect improvements to password storage practices
Over the years, Cerulean Studios, LLC's ("Cerulean") Trillian software has grown from a simple desktop client to a comprehensive service available on desktops, mobile devices, and the web (the "Trillian Services"). Accordingly, it's important to understand the differences between how Trillian connects on the desktop side, how Trillian connects on the mobile and web sides, and how Cerulean's servers and services operate and protect your data. To accomplish this, we've built a comprehensive Privacy Policy and this Security Practices document to let you know what information we collect when you use the Trillian Services and how we use that information to improve your service. The transparency provided within these documents is just one of the many steps we're taking as a part of our broader commitment to security, and we encourage you to read on and learn more.
Table of Contents
1. How Trillian Works On The Desktop
When you start Trillian on the desktop, a connection is made from your device to Cerulean's servers and authenticated with a unique Trillian username (your "Trillian Username") and password (your "Trillian Password") using our internally-developed instant messaging and presence protocol ("IMPP"). All IMPP connections are always protected with the industry standard Transport Layer Security Protocol ("TLS"). IMPP serves two purposes:
1. To expose a complete instant messaging environment including text IM, file transfers, voice and video, and visibility lists. For example, two people with Trillian can communicate using IMPP without the need for any additional third-party accounts.
2. To act as the synchronization engine between devices in the event that multiple devices are connected at the same time. For example, Trillian's continuous client feature relies on communication between your desktop and phone to keep chats in sync; this communication is done using IMPP.
Connections to third-party instant messaging service providers, when available, are made directly from your device to the third-party provider you choose to connect to. Many third-party providers now offer the option to use TLS when communicating with them, and Trillian uses TLS whenever possible.
2. How Trillian Works On Mobile and Web Devices
When you start a version of Trillian on a mobile device, a connection is made from your device to Cerulean's servers and authenticated with your Trillian Username using our internally-developed, HTTP-based "Octopus" protocol. All Octopus connections are protected with TLS.
The purpose of the Octopus servers is to host Trillian sessions on your behalf and communicate with your device exclusively using the HTTP protocol. This eliminates the need for your mobile device to maintain connections to different IM services and provides additional resilience against both volatile network connections and the unavailability of application backgrounding on certain mobile platforms.
3. Certifications and Compliance
Cerulean has received HITRUST CSF certification and a copy of Cerulean's most recent letter of certification is available at https://trillian.im/hitrust/. The environment that hosts the Trillian Services maintains multiple certifications for its data centers, including PCI Certification, and undergoes periodic audits under AICPA AT 101 (i.e., SOC 2 audits). Additional information about the certifications and compliance status of our data center operators, subject to confidentiality clauses, is available upon request.
4. Physical Security
Cerulean's servers are housed in SOC 2 Type II data centers within nondescript facilities. Physical access is strictly controlled both at the perimeter and at building ingress points by professional security staff utilizing video surveillance, intrusion detection systems, and other electronic means. Authorized staff must pass two-factor authentication a minimum of two times to access datacenter floors.
5. Remote Access Security
All remote access to Cerulean's servers and devices is done using secure protocols like SSH and HTTPS. In addition, access to all devices for administrative reasons is firewalled when possible; for example, a public-facing webserver will need to open access to TCP ports 80 and 443, but the SSH port will be firewalled to an administrative IP range only.
6. Personnel Security
Cerulean's employees are required to conduct themselves in a manner consistent with our internal guidelines regarding confidentiality, business ethics, appropriate usage, and professional standards. We conduct background checks on all new employees before employment and require that everyone reads and signs a confidentiality agreement.
7. Subprocessor Security
Before onboarding Subprocessors, we conduct an audit of the security and privacy practices of the Subprocessor to ensure they provide a level of security and privacy appropriate to their access to data and the scope of the services they are engaged to provide. Once we've assessed the risks presented by the Subprocessor, they are then required to enter into appropriate security, confidentiality and privacy contract terms.
8. Server Security
Cerulean's servers run a locked down version of CentOS Linux. We perform automated vulnerability scans on our servers and remediate any findings that present a risk to our environment. We also enforce screen lockouts and the usage of full disk encryption for all company devices, including laptops and mobile devices.
9. Centralized Logging
Cerulean has built and deployed a centralized logging solution for our production environment which contains information pertaining to security, monitoring, availability, access, and other metrics about the Trillian Services. These logs are constantly analyzed for security events by our security team.
10. Incident Management and Response
In the event of a security breach, Cerulean will promptly notify you of any unauthorized access to your data. We have incident management policies and procedures in place to handle such an event.
11. Encryption
All customer data is encrypted at rest via a combination of disk-level encryption (e.g., Bitlocker, LUKS) and file-level encryption (e.g., database-specific encryption methods). In addition, all communication to the Trillian Services is protected with TLS, and we follow two important practices when implementing TLS on both clients and servers:
1. When connecting to a server, clients attempt to check to ensure server certificates have been signed by an approved certificate authority. Clients also attempt to check to ensure that the name asserted by a server matches the name expected by the client. In the event that either of these conditions is not met, a warning is presented to you and the connection itself is terminated.
2. When possible, our clients and servers favor the use of key exchange mechanisms that provide the forward secrecy property, meaning that an attacker who compromises one of our long-term keys will not be able to compromise past TLS sessions. Our clients and servers always prefer the use of the latest recommended secure cipher suites and protocols to encrypt all traffic in transit.
12. Your Trillian Password
Your Trillian Password is not stored in plaintext. Instead, your password is used as the input to the PBKDF2 HMAC-SHA256 key derivation function. A SHA-256 hash of the resulting 32 byte derived key is then stored on our servers for authentication purposes along with a corresponding 32 byte salt; the salt is unique to each user and to each password. We currently utilize 86,000 rounds of PBKDF2.
Authentication happens in the following order:
1. The client establishes a TLS-secured connection to the server.
2. The client securely sends its username and password to the server.
3. The server looks up the salt and derived key associated with the username it received from the client.
4. The server derives a key using the password it received from the client and the salt it just looked up.
5. If the newly-derived key matches the derived key stored in the database, authentication succeeds.
We use key derivation so that individual passwords are unreadable by intruders (because the passwords are not stored in plaintext) and unusable for authentication purposes (because keys stored in the database are never sent to us directly by clients). The best method of breaking a derived key is therefore to brute force all possible password combinations, which should take a large enough amount of time that customers should have a chance to change their password(s) in the event of a security breach. We have the ability to increase the number of PBKDF2 rounds transparently to you, and we will continue to increase the rounds as our hardware improves, ensuring we maintain a reasonable balance between security and server performance.