Private link

Ever wanted to generate a short URL for sensitive content? Every short URL created in the Fynlink platform has the option to set it as a private link!

What is a private link?

All your link data including short URL, target URLs (including geo targets & device targets), title, note, tags are end-to-end encrypted. Meaning they are encrypted in your browser before they are sent to our servers with a key that we do not store. This means only you or your team members can view the link content.

For private link, the short URL is hashed and the target URL is encrypted using a key derived from the actual short URL. And the short URL (hash value) is encrypted using our standard searchable field-level encryption. You can learn more about encryption used here.

It is also important to note that, every link created in Fynlink will have a hashed short URL (which is further encrypted with a searchable field-level encryption) and an target URL encrypted with a key derived from the actual short URL. This is true for both private and normal links. What is special about private link is that, there will be no copy of end-to-end encrypted short URL & target URL in our database. This means, there is no way for us to show your short URL and target URL back to you, making it essentially a hidden link, but still works like a normal link for the end user!

⚡ What does it mean to you as our customer?

Making a link as private means, the short URL and its target is kept as a secret! No one, but only the person who created the short URL and the person with whom it is shared with, knows about it. This can be a better option for many for sharing sensitive links.

• All the analytics available for a normal link is also available for any private links.
• You can add tags, notes and title to a private link like normal links, and these data except notes are searchable in our platform.
• A private link will not show short URL or target URL in our platform. This is because we simply cannot as we do not know the encryption key for those!
• We ourselves use private links, in our password reset and account confirmation emails. You can read more about our use case here.

⚡ What does it mean to an end user?

For an end user, it is just like any normal short URL. When the private short URL is entered in the browser, it will be redirected to the provided target URL.

⚡ How does it actually work if we do not have the encryption key?

When a user enters a private short link in the browser, this is what happens next:

• We will search the database with two values for the possible existence of record. The actual short URL and the hash value of the short URL. All the searches are performed on already encrypted values. Remember, we use searchable field-level encryption for certain sensitive fields including short URL?
• If a record is obtained for the normal short URL, then it is a normal link, and we will redirect the user to its target URL.
• If the record is obtained for the hash value, we know it is a private link and an encryption key will be generated on the fly using the actual short URL. It will fetch the contents of the target URL and will decrypt on the fly using the created encryption key. The user will be redirected to the decrypted target URL.

⚡ Will setting a short URL private affect performance?

Most of the time the redirection happens from the cache and there will be no performance differences. Don't worry the cache values are encrypted using the same technique as a private link, meaning all links irrespective of they are private or not are encrypted using a key derived from the actual short URL!

Technically, it may take more time to redirect a link (both private and normal) when accessing directly from the database (when the data is not available in the cache). But the time difference will not be something to bother, and the redirection will be quick!

⚡ How is a private link stored in cache?

We use a key-value store (KV) as our link cache. The short URL itself will act as the key and the long target URL will be the value.

• The key always contain the hash (non-reversible) of the short URL. We do not store a short URL as plain text in our cache system regardless of a link is private or not.
• The value will always be encrypted. It is encrypted using a key derived from the actual short URL.
• The key-value store is already encrypted at rest (EAR) and in transit (EIT).

The more technical aspects of a private link

Learn exactly what algorithms and techniques we use to store your data securely! Both the primary database and KV store (cache) is encrypted by default at rest (EAR) and in transit (EIT).

⚡ What algorithm is used for hashing a short URL?

If a link is created as private, the short URL will be stored using a secure hash algorithm, precisely as a SHA-256 hash value.

⚡ What encryption is used to store a private link in our primary database?

When a link is created as private, the target URL will be encrypted using AES-256 CBC algorithm with an encryption key derived from the actual short URL using HKDF.

The hashed short URL is encrypted using the standard searchable field-level encryption with the help of CipherSweet.

⚡ What encryption is used to store a private link in cache?

Just like in the primary database, the target URL will be encrypted using AES-256 CBC algorithm with an encryption key derived from the actual short URL using HKDF. The key will be hashed short URL using the secure hashing algorithm SHA-256. The only difference is that, the hashed value is not again encrypted here and irrespective of a link type, this applies to all links in the cache. Also keep in mind, the cache is encrypted at rest (EAR) and in transit (EIT).