Hi Roy,

To provide some feedback here...a client that I am working with requires AES-CBC encryption with a minimum 128 key length. Storage wise for the key, they are OK with database or filesystem as long as there is sufficient internal controls around those storage locations (ie. access controls).

@Vitaly, I read your comment in CWD-1876. While I agree with you that this is a chicken and the egg scenario where we need to store a key somewhere to make this work and it is definitely a case of "security by obscurity", I think it is important that Atlassian keep in mind that this is a fairly standard requirement for alot of security policies and it will improve the 'ease of implementation and maintenance' in these environments if not greatly improving security.

Regards,

Ram

Mike:

This is a single password used for JIRA itself to connect to the LDAP server. Not user passwords.

mmitchell1: You seem to have misunderstood what this issue is talking about. User passwords in general are not stored in plain text in the database. The internal directory passwords (those that do not live in an external system and JIRA therefore has the responsibility of authenticating) are stored as a cryptographically strong salted hash. You can read a description of the algorithm here. When a remote system performs authentication (such as with a Delegated LDAP configuration), JIRA relays the user-provided password to LDAP without persisting it in any form whatever.

However, there are certain passwords that JIRA itself must know because JIRA is itself the authenticating client. For example, end users do not enter the database password for JIRA to pass on; JIRA must itself know the database password. We could hide it in some way, but since JIRA has to get access to it, anything we did would have be reversible obfuscation rather than a salted hash. Similar examples include the passphrase for the private key assigned to a webserver and, as this issue concerns, the password that JIRA uses to authenticate itself with an LDAP server so that it can perform user database synchronization and other similar administrative tasks.

So this is not merely something that "the development team can't think of a way to address"; rather, it is demonstrably impossible to make a secure hash work here because JIRA is a client that must provide said password to another system. We could use some kind of obfuscation to "guard" these passwords against casual observers, but this does not actually improve security in any real sense and we might get accused of misleading people into thinking the password is now secured, when in fact it isn't. As one of our security experts phrased it: Security by obscurity would alleviate the concerns of the clueless, at the same time the more clued in "security researchers" will start reporting a "security vulnerability" about reversible encryption.

To date, our thinking has been that if JIRA has to have access to the password, we should not do anything that falsely pretends it is in any way secure. I do not entirely agree with this assessment myself. Given that JIRA must have access to these passwords and that it not having access to them at all is off the table, let me state how I would answer Roy's question:

Please make the storage of passwords that JIRA must access pass through a replaceable library so that I may re-implement that storage in a way that will comply with my company's policies. I'm considering the purchase of a hardware encryption device specifically so that people who gain access to sensitive data cannot decrypt it without access to that device, and I need this integration point to make certain that if my database or a backup of it is compromised, that will not immediately escalate to a compromised LDAP server from there.

Roy,

The passwords should not be stored at all, you should be using tokens with expiration once a user has authenticated by AD.

If the passwords must be stored in DB they must be hashed (one-way function, protects against decrypting passwords) + salt (protects against rainbow tables attacks).
1. Hash functions should be secure and collision free:
a. Good hash functions: SHA256
b. Insecure hash functions: MD5, SHA1
2. Salt requirements:
a. Salt should not be reused.
b. Strong salts should be used. Example: NT5c5SXsNsk3zhZ

Q1 -Could you please explain in detail why the passwords are kept in the DB?
Q2- Also could you tell me how the local directory user passwords are stored in the DB?

Good read: https://crackstation.net/hashing-security.htm

Mike,

I'm not saying that at all. I'm asking you for feedback on what you think is the minimum you would need in your company.

For example, if the password was simply obfuscated would that be enough? Even if the method for obfuscating was in the JIRA source?

So you are saying that the development team can't think of a way to address ?

mmitchell1,

At the moment the we feel like this is something we won't be addressing at this time.

However, we're looking for input on how customers would like to see this addressed - please see my previous comment.

Cheers,
Roy

What is the target date to address this issue?

Same as in CWD-1876, I think this is a won't fix.

This is not something that's on our immediate plans to fix but we are interested in understanding how our customers would prefer this to be implemented in JIRA.

There are a number of security factors to think about here, for example:

• Is hashing the LDAP password enough? Even though it could be easily reversed.
• Have an encryption with a securely generated key that is stored elsewhere, but where would we store it?
• Any other security concerns?

Regards,
Roy