White paper: transport and data security


The communication channel between Hansel SDK and the Hansel servers is secured at multiple layers.

Data Layer:

  1. The SDK requests are signed and any tampering would render them invalid. The signing works on a time based key over a symmetric key algorithm.
  2. The response is encrypted using symmetric key algorithm and the key is different for each app version of every company.
  3. This encrypted data is then signed using an asymmetric RSA algorithm involving public and private key. Any tampering of patch would render the signatures as well as the response, invalid.

Transport layer security (HTTPS):

All the communication between the SDK and the Hansel servers happens over the HTTPs layer.


In case of invalid request (wrong signature/encryption), the servers reject the request and SDK rejects the response.


Transport layer security:

All the communication from the browser to the Hansel servers happens over the HTTPs layer.

Application level security:

  1. A user is recognized with the session ids which are changed every 24 hours.
  2. For every request that adds/updates/deletes patches from a given app, we validate that the app actually belongs to the company that is requesting the change


  1. Company passwords are hashed using state of the art PBKDF2 algorithm with a SHA256 hash, a password stretching mechanism recommended by NIST.
  2. All the information saved in the database is encrypted using a company specific key.
  3. The database cluster and the ports can be accessed only from already specified list of IPs. These IPs are local to the network in which the database cluster resides. No request from external environment to the DB will be honoured.
  4. Remote logins to the database are disabled.
  5. Databases are cloned as well as backed up at regular intervals to enable redundancy and prevent loss of data.
Have more questions? Submit a request


Please sign in to leave a comment.