Where the encryption key should preferably be stored

Jira Development Jira Data Center
,
1

Our plugin uses encryption to store encrypted credentials data. Which we then decrypt and use in our api.
Therefore, we would like to know where it is preferable to store the key used for encryption and decryption.
We have not found a clause on this topic in the developer documentation.

2 Likes
2

Did you ever find a solution?

3

Hi @NikolayShmakov @BrunoMarotta,
i’m not sure if it will work within a jira plugin but have you tried to use a Java KeyStore (JKS)?
With Java it is a common approach for managing encryption keys and certificates within a Java KeyStore.

Here are some steps that may help you to integrate a Java KeyStore into your Jira plugin:

  1. Create the KeyStore: Generate a KeyStore file (e.g., keystore.jks) using the keytool command:
keytool -genkeypair -alias myalias -keyalg RSA -keystore keystore.jks
  1. Import Certificates: If you need to import certificates into the KeyStore, use the following command:
keytool -import -alias myalias -file mycert.crt -keystore keystore.jks
  1. Configure Jira to Use the KeyStore: Set the system properties to point to your KeyStore file and its password in your plugin’s code:
System.setProperty("javax.net.ssl.keyStore", "path/to/keystore.jks");
System.setProperty("javax.net.ssl.keyStorePassword", "yourKeystorePassword");
  1. Access the KeyStore in Your Plugin: Use the KeyStore class to load and manage the KeyStore within your plugin:
KeyStore keyStore = KeyStore.getInstance(KeyStore.getDefaultType());
FileInputStream fis = new FileInputStream("path/to/keystore.jks");
keyStore.load(fis, "yourKeystorePassword".toCharArray());
  1. Handle Encryption and Decryption: Use the loaded KeyStore to perform encryption and decryption operations as needed in your plugin.

Maybe it helps :slight_smile:

Cheers,
Daniel

4

@DanielGrabke
Greetings. Thanks for the example.
Unfortunately I need a little bit different.
First, in this solution our generated key will be freely available through the ability to extract it directly from the “.jar” plugin. The only way to solve this problem is to split the key into two parts, public/private and generate a unique key for the client on the side of a specific service created and supported by us, I have no desire to lock clients under such a restriction, it is not a secure solution.
Secondly, we need to create a unique key for each client to encrypt his data.

And the question is where is the best place to store such a key. After all, if we store it in the database, and it is leaked, we actually leave our data open to attackers. Or should we just ignore such a scenario and assume that once the database is leaked, there is nothing we can do? Or should we split the key into two parts, the database and the shared-folder key? This way an attacker will need not only access to the database, but also access to the shared-folder.

5

Hi @ NikolayShmakov,
i havent done this kind of key storage so far and i’m not a security expert but i asked mycolleagues for an advice:

1. Avoid Storing Keys in the Database Alone

Storing encryption keys directly in the database can be risky, as a database breach could expose them.

2. Key Splitting (Shamir’s Secret Sharing)

Splitting the key into two or more parts and storing them separately can enhance security. This technique, known as Shamir’s Secret Sharing, ensures that an attacker would need to compromise multiple storage locations to access the full key. You can store one part in the database and another in a secure shared folder.

3. Secrets Management Tools

Using a secrets management tool like HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault can provide a secure and managed environment for storing encryption keys. These tools offer features like automated key rotation, access control, and audit logging.

4. Environment Variables

For applications running on servers, storing encryption keys in environment variables is a practical option. Ensure that these environment variables are managed securely and not exposed in logs or error messages.

Combining Strategies for Enhanced Security

I would consider combining some of these strategies to mitigate risks:

  1. Key Splitting and Secrets Management:
  • Split the key into parts: Store part of the key in a secure, encrypted database and another part in a secrets management tool or secure shared folder.
  • Retrieve and combine the key parts at runtime within a secure environment.
  1. Environment Variables and Secrets Management:
  • Store the encryption key in a secrets management tool.
  • Use environment variables to retrieve the key at runtime, ensuring it’s not hard-coded in your codebase.

Hopefully it will help :slight_smile:

Cheers
Daniel

6

Hi @DanielGrabke ,

Thanks. But if you are not an expert, you shouldn’t simply copy/paste ChatGPT generic answers in this community. We all know how ChatGPT works, we can ask the questions ourselves and answers are unreliable and seldomly works for niche technologies like Jira.

@NikolayShmakov : You should not store the keys in the database. The keystore is a promising idea, but the question is if it will work inside of a Jira plugin and if there are going to be side-effects (like having the keys wiped out on a major Jira upgrade).

I just find it curious that no one in this community never had the need to store a password or key in a Jira plugin and that Atlassian doesn’t have a solution for that.

7

@BrunoMarotta
Thanks for the notice.

I’m intimidated by KeyStore because I’m not sure how the client will store their data. The database will effectively exist forever and we won’t lose its data. However, with the plugin data being stored somewhere else other than the DB is anxiety provoking. Anxiety in regards to the client having to re-enter their credentials if they lose the shared-folder data.
The reason for this can be anything. Whether it’s moving the cluster to a different hardware, or whether it’s data corruption.
In general, despite my worries, it looks like we’ll have to stick to shared-folder as well.

In this regard, I do not consider the solution based on environment variables as reasonable at all, firstly they can be rewritten, secondly they can be read by anyone, thirdly they are stored on each node separately, not in the cluster as a whole.

It seems more reasonable to split the key into two parts and store one part on a shared folder (using KeyStore) and the other part in the database (encryption-key/password for KeyStore). This way, even if one part of the key is compromised, it will not be enough to gain full access.

8

Just thinking out loud here, instead of creating a separate key / logic… Since few releases Jira DC enforces the encryption of secrets and stores the key in /keys/…

I would check the source code if these methods could be re-used by an app to encrypt own data with the same technique.

9

@tied
That’s the point of the original question :slight_smile:
Atlassian knows their product better and instead of us trying to guess what is responsible for what and what can be used and what can’t. It would be better to get an answer from the developer company.

1 Like