I found out this ticket while going around database for Active Directory reporting (using cwd_directory & cwd_directory_attribute).

I had to double check the password in KeePass to be sure it was the actual production password.

We are in 2019 now. In 2019 it is completely insane to assume that clear text passwords are OK. Final point.

Use case 1 : Reporting from direct access to database

It is when someone wants to have direct reporting means from database endpoint. Which is my case.

Of course you could/should have a read only database user and prevent it from accessing sensitive tables.

But how in the first place do you know about that? How one is aware of where passwords are "hidden" when willing to secure the database for reporting purposes?

A very obvious method is to store credentials using a dedicated mean where only the Jira system account is able to decrypt the passwords or using a storage/key outside of the database. This could be a key on file system (XML whatever) requiring system account / root access on file system.

Why ? Because a server is not always compromised by gaining root access on the filesystem but also often by misconfigured securities.

Use case 2 : Interception by third parties

Another stupid case, the password is in plain text in the PostgreSQL database dumps.  Which is my case too.

No one ever should be allowed to read a password in plain text. Even if this involves being a backup operator.

Only allowed situation for clear text password

Post-it at the back of a keyword. Just Kidding.

About challenge-response type authentication.

Is there anything planned after 5 years when dealing with Windows LDAP servers?

I think this should be a won't fix. This is a chicken and egg scenario - since Crowd has to be able to recover the password in order to connect to those systems, there will always be a key or a password or an algorithm that, applied to the "encrypted" passwords, will restore them. We're talking a minor improvement at most, and more likely useless security by obscurity type of improvement.

When those external systems support, for example, challenge-response type authentication, we can revisit this improvement.

An implementation that uses a key stored in crowd.cfg.xml and uses it to encrypt any passwords before storing them in a database seems like the best option.

The key should probably be generated randomly, rather than provided by an admin. Should this be an opt-in feature, or should passwords stored in the DB be unconditionally encrypted?

For upgrades, how to distinguish encrypted passwords in the database? Storing them as encrypted:k/UawjeqiIlfdO4NCxwzdxVRCl3PFjYos2dF3I8vGEA= would work, except for the case where an existing password happened to start with 'encrypted:'. That seems unlikely enough that it's probably an acceptable approach.

We can roll something with AES, Base64-encoded, but we should follow existing standards or conventions, if there's anything related.

Storing a key outside the database and using it to encrypt any credentials stored in the database would help in some cases. This would improve security in the case of an attacker getting access to Crowd's database without being able to read the filing system of crowd.home. If we included this key in the backup it should be commented to warn that it allows decryption of passwords.

Without this feature, many compliance-oriented enterprises under SAS 70 Level 2, SOX/GLBC, HIPAA, PCI-DSS to name a few will avoid Crowd.

The only two way hash is that given by rainbowtables, but you didn't here it from me.

Well, first you have to be clear on the attacks/attack vectors you want to protect against; otherwise the terms "encrypted" and "secure" are all just marketing.

You're absolutely correct on my use of "2-way hash". Mea culpa.

Shihab's said everything else.

Yep - I've also not heard of a 2-way hash

I've updated issue to say "encrypted" (ie. recoverable password for use when connecting to LDAP/Mail Servers).

As you stated, the hardest part is securely storing the key. We are yet to decide on a consistent approach to solving this problem for Atlassian applications and appreciate your suggestions. We will update this issue once an approach is agreed upon.

Is it just me who's immediately skeptical of the phrase "2-way hashed"? "Cryptographic hash" implies "one-way".

I'm potentially in favour of a scheme where passwords are sensibly encrypted (AES-128 CBC) with a "master key" explicitly not in the database (e.g. in a secret file somewhere). This offers a few benefits:

• Passwords are no longer accessible to the database user (e.g. postgres) or via database backups.
• Sysadmins are less likely to inadvertently see someone's password.

And obvious problems:

• The master key must be kept separate for this to work
• The master key needs to be restored separately
• End-users get confused

If the master key isn't stored separately, then the word you're looking for is "obfuscate".