As of JIRA 4.3 we have moved away from using the osuser.xml file. It is still recognized for upgrade processes, but configuring new LDAP setups now go through the JIRA administration interface and stored within the database. More information on this here:
http://confluence.atlassian.com/display/JIRA/Connecting+to+an+LDAP+Directory

The current issue now is that the password stored in the database is still plain text. I have created a new request for this, found here: JRA-27457

However, any improvement is surely better than none.

We usually deal with security issues on the basis of risk/effort trade-off. Of course, the risk component is of much higher importance than the effort required to fix it.

Vitaly, I agree that the solutions I posted are a minimal improvement over leaving the passwords in clear text. However, any improvement is surely better than none.
Regards
Robin

Robin,

We consider encryption with passwords stored right beside in the application code security by obscurity. This provides minimal improvements compared to not encrypting the passwords and using OS permissions to protect credential files instead.
Incidentally, this:

so that only the application running as Root can read it

appears to be a misguided approach - requiring the application to run as a privileged user leads to much higher impact when the application is compromised. The common practice is to run them under a non-privileged account and set up file permissions so that only this user can access credentials file. For example, JIRA installer creates a dedicated account and restricts access to files and directories accordingly.

Hi Vitaly - thanks for following up. Our security department has standards that we need to code to for internally developed software. For vendor applications there is a little more latitude. Some sulutions that are in use by some of our vendors include: providing an api and leveraging Cloakware (which we have implemented here); encrypting the password using their own algorithm before storing it anywhere; saving the password in a configuration file that (on Unix/Linux systems) can be locked down so that only the application running as Root can read it. The bottom line is that we are not allowed to use software that stores passwords in clear text and the last option I listed above is really a case of last resort for vendor applications that cannot do anything better. With JIRA, I recall that before we implemented the LDAP solution here the user passwords were stored in an encypted form in the database. Now our user passwords are stored only in LDAP which is great, but I wonder if JIRA still contains the encryption methodology and could leverage that on the system passwords that it stores?

Regards
Robin

Robin,

What is your security department's recommendation on storing the password that is used for encrypting the system passwords? This is a somewhat circular problem and we would really like to learn how other people solve it.

Our corporate security standards require all passwords to be encrypted. JIRA is storing system passwords in clear text and that is not acceptable to our security department.

Nikhil,

Could you please elaborate on how (using your words) "false sense of security" would help you implement JIRA? As mentioned in linked tickets, it is not possible to completely eliminate storing a password somewhere. The account in question is a limited privilege account or at least it should be configured as such.

We do not want to mislead anyone and in your specific case there may be something to be improved in the decision making process, not in the product. You way want to talk to you security auditors to help them understand the level of risk this minor design decision creates and whether it this level of risk is acceptable for your business in the view of business benefits that JIRA gives you.

This is a feature that should be added ASAP, even though this is a false sense of security. for my organization, since we are planning to have JIRA installation inside the data center, this could result in a go-nogo decision. We are right now evaluating JIRA with a 10 user license and are planning to move to a 100 user one once the evaluation is successful.

I work for a financial comapany and having this feature of encryption the password is a necessity.