When working with Kuva Media for your custom projects, there may be times when our team will need to access certain apps, software, or databases, or senstive information you'll need to provide, in order to provide service.
We have two option to securely exchange sensitive information, depending on the use-case:
Option 1: Add Kuva Media as a special access user, such as Developer, Contributor, Collaborator, etc.
When possible, we recommend providing access through developer or collaborator credentials, that may be built into the applicable software or technology involved in your service.
If adding Kuva Media as a user is not possible, or if the project requires full access credentials, then Kuva Media can offer the next option:
Option 2: Sending sensitive information through secure, encrypted, one-time use links
How to use it
If you need to send or receive sensitive information, we'll provide a Request Link or send a Secret, using encrypted software.
For sending information, simply send the information through the provided link, and it will be delivered to Kuva Media, to a secure portal.
How it works
When a new one-time link for a secret is created, the following happens:
- First two 18 characters long random strings are securely generated in the browser. We can call these public and private encryption key parts.
- Then the secret is encrypted in the browser using AES-256-GCM using an encryption key which is a concatenation of the public and private encryption key parts.
- The encrypted secret and the private encryption key are sent to our secure link service's backend server and stored into a database. The backend server returns an ID for the stored secret.
- The browser generates the one-time link using the returned ID of the secret and the public encryption key part. The public encryption key part is never sent to the server and is only known to the browser.
Given the nature of the service and the fact that it partly runs on the browser, security and privacy are extremely important.
Using the described process ensures that neither the browser nor backend server never have full information required to encrypt the secret - both the data in the link (public encryption key part) and the data in the database (encrypted secret and private encryption key part) are always needed to encrypt the secret.
When the one-time link is opened in the browser, the backend server sends the encrypted secret and the private encryption key part to the browser. Using that information and the public encryption key part in the one-time link, the browser is able to decrypt the encrypted secret.
The backend server will never see the public encryption key part because it is stored in the link using a fragment identifier (#). A browser does not send the fragment identifier to a server, so it cannot be seen or logged by it.
The backend server allows fetching the data of the secret only once, so the link can only be opened one time. After the data has been fetched, the backend server deletes the encrypted secret and private encryption key part from the database making it impossible to fetch the secret again.
Additional details:
- Uses technologies like Content Security Policy, Strict Transport Security and Secure Cookies to protect against known and unknown security threats.
- No tracking scripts or cookies are used.
- The service does not load any external JavaScript on the pages which handle secrets to make sure no malicious scripts are injected into the pages.
- The service works only on HTTPS to ensure encrypted communications.
- All data stored in the service's databases is encrypted at rest.