Simplisync’s Security Details

General practices

• Access to servers, source code, and third-party tools are secured with two-factor auth.
• We use strong, randomly-generated passwords that are never re-used.
• Employees and contractors are given the lowest level of access that allows them to get their work done. This rarely includes access to production systems or data.
• We use automatic security vulnerability detection tools to alert us when our dependencies have known security issues. We are aggressive about applying patches and deploying quickly.
• We don’t copy production data to external devices (like personal laptops).

Access control and organizational security

Personnel

Our employees and contractors sign an NDA before gaining access to sensitive information.

Penetration testing

We had a penetration test performed in August of 2024. The assessment concluded that “the security posture of the Simplisync was found to be in line with industry’s best practices.” If you’d like a full copy of the results, send us an email. 

Authentication

At sign-up, each customer is given an invite link to share with their team. Each team member can use that link to set up a new account with their email and password. User passwords are hashed using bcrypt before being stored. When a user logs in, they are given a 20-byte authentication token, generated with the SecureRandom tool in the Ruby Standard Library. The token is invalidated after 30 days of inactivity. All further interaction with the API is done by providing an Authorization header with this token.

Encryption

Definitions

• Data -Data - Clicks, keystrokes, drawings, animations, etc.

• Media -Video (webcam and screenshare) and audio

All data and media during a 2 or 3-person pairing session are sent peer-to-peer (avoiding our servers) and are encrypted end-to-end. All data during a call with 4 or more participants are sent peer-to-peer. Media is sent end-to-end encrypted and relayed through our media servers.

When we say “end-to-end”, we mean it in the way you’d expect: your data and media is not (and cannot be!) decrypted by anything other than the clients involved in the call. Stated another way: the only people that can see anything that happens in a pairing session are its participants.

Data channels in peer-to-peer connections are encrypted using Datagram Transport Layer Security (DTLS) version 1.2, while media streams are encrypted using Secure Real-time Transport Protocol (SRTP).

When there are 4 or more participants on a call, encrypted media streams are relayed through our servers using SRTP. Each frame in the stream is encoded using AES-256 encryption. Keys are randomly generated by each participant and are never reused. Keys are exchanged using peer-to-peer data channels over DTLS. We do not store any user media on these servers. Our servers never have access to the keys and cannot decode any media.

Data flows

All logged-in users are connected to a signaling server using the WebSocket protocol.

When a Simplisync client wants to initiate a call, it sends an “Offer” through the signaling server and identifies the recipient of the call. The server then pushes that message to the intended recipient. The user on the receiving end will be prompted with an incoming call and can accept or decline. If the user accepts, the client sends an “Answer” and the peers then negotiate an encrypted connection. The peers exchange keys directly through an encrypted tunnel. The keys are never sent in plain text.

In most cases, both peers will be able to identify addressable IPs and ports on which to establish a peer-to-peer connection using the STUN protocol. Under some restrictive firewall configurations, this is impossible and traffic must be routed through an intermediate server using the TURN protocol. These servers cannot decrypt the contents of the data packets, and only route based on the UDP layer. Under no circumstances does video, audio, keystrokes, cursor movements, or clipboard data pass through our servers when using the TURN protocol.

Data retention/logging

Logs are stored separate from our backend infrastructure in a private CloudWatch area.

These logs are retained for 30 days, after which they are permanently deleted.

Application analytics can be permanently deleted on request.

Software development practices

• Code written by any developer is signed off by at least one other person before committing.
• Code is tested in a staging environment against a QA checklist before deploying to production.
• The Simplisync client is code-signed and has the Hardened Runtime mode enabled (which protects against code injection, DLL hijacking, and process memory space tampering).
• The Simplisync client is automatically scanned for malware and notarized on every deploy.

Vulnerability detection

Both the client and our backend are regularly scanned for dependencies with known security vulnerabilities.

Vulnerable dependencies are patched and redeployed rapidly.

FAQs

How are keys exchanged between clients?

When two peers begin a call, the first step is to exchange keys for encrypting the communication. This happens directly between the peers. The exchange is encrypted with DTLS (a derivative of SSL). The clients use a self signed certificate (asymmetric-key) based on RSA to exchange the keys they will use. Thus, the exchange of keys is a) encrypted and b) done directly peer-to-peer. The packets never touch any servers under our control. We cannot intercept the exchange of keys and would see only encrypted data if we tried. Also, the code that handles this exchange is from WebRTC, which is open-source, frequently audited, and primarily written and maintained by Google’s security experts.