-
-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[JIRA] plugin store credentials in base64 #15718
Comments
This issue has gone three weeks without activity. In another week, I will close it. But! If you comment or otherwise update it, I will reset the clock, and if you label it "A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀 |
@mbarbey sorry this got stale. I'm thinking about how to fix this but can't really find a good solution as even if we encrypt the credentials, we'd still need to make the key available to the app to decrypt on-demand which defeats the purpose. Am I missing something here? |
@BYK I wasn't thinking about a sophisticated solution. I see 2 possible solutions, one very easy and one easy : 1. very easySimply generating a random key at the installation, storing it in a file somewhere in the project, and using this key to encrypt the credentials before storing it in the database. 2. easySame thing as the 1st option, but the file containing the encryption key is stored somewhere on the OS where the access is limited by users (like the .ssh directory on linux). It would probably be differents paths depending the OS so it might be a little more difficult than the 1st option, but not too much. And in both case, when migrating data to a new server, you will need to copy the security file to the new server or reconfigure the Jira plugin. What do you think about it ? |
When registering a JIRA instance in a project, the information and credentials are stored in plain base64 in the database, which mean that anybody able to connect to the database or read the dumps can log into the JIRA instance with the account of the linked user (which can be catastrophic depending the user's permissions).
I would suggest encoding these data in openssl aes256-cbc or any securized way to store sensitive data.
The text was updated successfully, but these errors were encountered: