🌈 Kinkdom.fun

Introduction

We envision Kinkdom as an exceptionally secure social platform, which is designed to protect your privacy and security in all aspects. So, we incorporate security into every functional and technical design decision we make.

At Kinkdom, we also believe that transparency is essential to be secure, so we are committed to be transparent about how we handle your data, and how we protect it. This is why we provide and made the following document public as a whitepaper, which describes the security measures and technical details we implemented to protect the service, so anybody can inspect it.

If you think you have found an area of improvement, please contact as at security@kinkdom.fun. In case you think you have found a vulnerable area, please use only the e-mail address above to report it, and do not disclose it publicly until we have a chance to fix it.

Domains

The service is operated under the following domain name: kinkdom.fun.

Automated e-mails are sent from email.kinkdom.fun.

How we protect your data?

Server side

Our service is hosted in the cloud and built on top of Platform-as-a-Service components, so all patching and medium level configurations are managed by the cloud provider.

All communication between our servers internally are secured by TLS 1.2.

Service components use passwordless authentication mechanism between each other, provided by the cloud platform, wherever possible.

Service components have only the least permissions granted.

Encryption keys are stored in a vault specifically designed for that purpose.

For user identity at application level, we use an implementation provided by the web framework we use with minimal customizations, which is maintained by the manufacturer.

Passwords are stored using one-way, standard cryptographic function PBKDF2-HMAC-SHA512. See details

Uploaded pictures and videos are scanned for malware.

All user media content served from CDN is protected with expiring links, which can only be issued with meeting proper authorization requirements.

Client side

All communication between our servers and your browser are secured by TLS 1.2.

We use standard HTTP headers to harden security in the browser:

• Strict-Transport-Security
• Expect-CT
• Content-Security-Policy

We use a web UI framework, which encodes text by default, to prevent Cross Site Scripting attacks.

We use Cross Site Request Forgery protection, to prevent unwanted user actions.

Before navigating to external links, users are prompted to double check and confirm the domain of the external site.

Your password never leaves the browser in an unencrypted form, it is encrypted using one-way, standard cryptographic function PBKDF2-HMAC-SHA512 right in the browser. See details

We use the Clear-Site-Data: "*" header to clear all browsing data on logout, if requested.

Cryptography

We use only standard encryption methods, and no custom one.

We use only standard encryption methods SubtleCrypto or System.Security.Cryptography

How we protect your data at rest?

For all data we store, we use FIPS 140-2 compliant encryption algorithms, and at least two layers of encryption at rest:

• (database) service-side encryption with AES-256
• additional layer of another AES-256 using infrastructure level encryption

For account data (e-mail address, passwords, salts, audit logs) we use another extra layer on the top of the two regular layers of encryption:

• client-side (server-side application) encryption with AES-256-GCM, each record with a different symmetric key
• for indexes and lookups we encrypt the data with one-way encryption HMAC-SHA-512

The symmetric encryption key is encrypted with a RSA-4096 key, which is stored in a non-exportable form, in a vault which is protected with HSM.

Encryption of account data:

Decryption of account data:

How we encrypt your passwords?

Passwords are encrypted in two phases to provide an extra layer of security:

1. We encrypt your password using a one-way encryption algorithm, right in your browser, so it never leaves your browser as plaintext, only in an already undecipherable form. First, we derive a key from your username using PBKDF2-HMAC-SHA512 with a dynamic iteration count calculated from your username. Then, we use this key as a salt for hashing your password using PBKDF2-HMAC-SHA512 with an iteration count of over 200,000.
2. (Your password hash is transferred from your browser over TLS 1.2 secure connection to our servers, so nobody can read the hash either in-between.)
3. Your password hash is received by our servers. At this stage, we can't tell what was your original password, we can only see a derived key. As a second phase, we derive another key from your password hash using PBKDF2-HMAC-SHA512 with another over 200,000 iterations, and this is your final password hash we store in our database.
4. (The password hash is then stored in our database with 3 independent rounds of AES-256 in total, where the symmetric encryption key is encrypted with a RSA-4096 key. See How we store your data)

Although we take the extra mile to protect your password, you should too:

• choose a password, which is complex enough and uses a wide range of characters
• do not use full words which can be found in a dictionary
• do not include any publicly available or guessable information (username, birth date, ...)
• do not reuse a password across multiple sites
• we encourage you to generate a random strong password using your browser or your password manager

How does e-mail sign-in work?

This method is similar to a Forgot Password flow in concept where we verify the ownership of the e-mail address.

1. The user enters its e-mail address on the sign-in page.
2. We verify the information, and if the e-mail address is valid, we send a one-time link to the e-mail address. The token has a 512-bit entropy and expires after 10 minutes.
3. Then the link can be redeemed only once and only from the same network that it was issued.

Issue e-mail sign-in token:

Redeem e-mail sign-in token:

How do we protect your session?

Your session data is encrypted using AES-256-GCM and validated using HMAC-SHA-512.

The encryption key is encrypted with a RSA-4096 key, which is stored in a non-exportable form, in a vault which is protected with HSM.

We store your login session in secure, http-only and same-site cookies, instead of in-memory tokens. This has two guarantees:

• It is the responsibility of the hosting context (the browser) to keep that secret safe, not the client application. This means that if our client application could be exploited by an attacker, they can't steal your session, because our application never sees that secret, in fact it has no permissions to view it at all.
• It is not like a JWT, which is only signed, but this is fully encrypted. So, if somebody would get access to your session data, they can't even identify who does it belong to, it can only be decrypted and interpreted by our backend.

For another extra layer of security, you can optionally choose to Restrict your session to this network endpoint, which means that even if somebody could acquire your session token, it cannot be used from any network endpoint other than the one you signed in from. In simple terms, an attacker cannot take control of your session from their computer. On the downside, anytime your network changes (e.g. on cellular network), your going to be prompted to revalidate your session and sign in again. So, while this can be a good choice if you browse from your home computer, it may not be on your phone or if you use a VPN.

How do we protect your data in transit?

All communication is secured by TLS 1.2.

How does End-to-End Encryption for chat work?

TODO

Continuous improvements

We follow new technology and security trends, monitor our systems, and continuously improve security of the service.

Vulnerability reports

Send your reports to security@kinkdom.fun.