Need to connect a Freenode channel to a room in HipChat? Or want to give customers a simple way to connect to a channel in your Slack team?

Sameroom does that!
Learn more

 Subscribe via RSS

Tag: minutiae

Facebook Login from Bulgaria

By @abs

Occasionally, when signing in to Sameroom with Facebook, you may see a warning, similar to this one:


As an immediate workaround, sign out of Facebook on the web, and then back in. Once you do that, you should be able to sign in to Sameroom.

Here are some additional details about this issue:

  1. Because Facebook doesn't provide an API for chat, we are forced to use use an approach similar to, where our server emulates a web browser.

  2. This means when you sign in to Sameroom with Facebook, Facebook treats this as a sign-in from another computer.

  3. Unfortunately, Facebook thinks our servers are in Bulgaria, which prompts a suspicious sign in warning message. (Our servers are actually in California.)

  4. The best way to ensure sign-in safety, opt-in for Login Approvals, described here:

    Once enabled, you can make sure you're giving access to Sameroom only, not someone actually in Bulgaria. To keep track of active sessions, go here:

    The Sameroom session will appear similar to this:


You have any questions, please contact us via in-app chat:


Sameroom Security Overview

Andrei Soroker, Peter Hizalev
LeChat, Inc.

August 2015.
Updated: February 2016.


Sameroom provides real-time interoperability between different instant messaging systems, such as Skype, Google Hangouts, Slack, HipChat, Fleep, and so on. The service requires the creation of “Tubes”—bridges between group or contacts in various providers—by using the Sameroom dashboard.

Because Sameroom interacts with different communication services on behalf of the user, it must store user credentials for each connected service, either in the form of an authentication token (OAuth), a security token, or a username and password combination.

The necessity to store such sensitive information means security is one of the key design goals for Sameroom. This paper explains the details behind various architectural and procedural decisions that address data security.

Sameroom does not have any provisions for persistent storage of message data. This means all questions concerning the safeguard of message histories fall entirely on service providers.

Sameroom never retrieves message history, working exclusively with data arriving in real time. Sameroom never writes messages to any persistent storage. Messages reside in RAM for a short time required for transmission across user-configured connections.

Data Security—Cryptographic Details

Sameroom stores user account credentials (OAuth tokens, security tokens, or passwords) using envelope encryption with AES256 [1] Cipher Block Chaining (CBC) [2].

Key management [3] is implemented with a Hardened Security Appliance (HSA) provided by the AWS Key Management Service (KMS) [4].

AWS KMS operates by establishing a domain as a cooperative collection of trusted entities (trusted entities are HSAs and human operators) within an AWS region. The Sameroom HSA is located in the us-east-1 region, US East (N. Virginia).

A domain includes a set of trusted entities, a set of rules, and a secret key, called the domain key. This key is shared through a domain state export routine—this state can be imported into any HSA within the domain. The domain key is rotated daily, to ensure compliance with NIST Recommendation for Key Management—Part 1 [5]. This key is shared among all HSAs within the domain.

During daily domain key rotation, all existing HSA keys encrypted under the outgoing domain key are re-encrypted with AES256 GCM [6] under the new active domain key. HSA keys are rotated annually, with deactivated keys preserved to decrypt old ciphertexts. An HSA key is used to encrypt the data key with AES256 GCM and, optionally, additionally authenticated data (AAD).

A separate data key is issued to encrypt the credentials of each Sameroom account. The corresponding AAD includes an immutable account identifier. The per-account data key is used to encrypt the plaintext of account credentials with AES256 CBC. The resulting ciphertext and the data key ciphertext are combined into an envelope, which is stored in the Sameroom database.

HSA and data keys are never stored in plaintext. The keys are only available in plaintext (in RAM) very briefly, to perform the cryptographic operation. Encrypted data keys are only stored in the Sameroom database. Encrypted HSA keys are only stored within the AWS KMS and are never exposed outside the KMS. See [7] for a detailed description of the KMS HSA operation.

In addition to encrypting account credentials, Sameroom uses EBS encrypted volumes to store database files. EBS encryption uses AES256 XTS [8] and the Sameroom KMS HSA described above. See [7] for a detailed description of EBS encryption.


The Sameroom network and production environment are only accessible by personnel with appropriate security clearance, through a Virtual Private Network (VPN). VPN keys are never transmitted over the network.

Reporting Security Issues

If you find any security concerns with the Sameroom platform, please send your report to


[1] Advanced Encryption Standard

[2] Cipher Block Chaining (CBC)

[3] Key management

[4] AWS Key Management Service

[5] Recommendation for Key Management–Part 1: General (Revision 3)

[6] Galois/Counter Mode

[7] AWS Key Management Service Cryptographic Details

[8] XEX-based tweaked-codebook mode with ciphertext stealing (XTS)