Remember support changing the passwords without starting Confluence - the system won't start up if the DB password is incorrect and the passwords do change occasionally.

This is also the case for Confluence's LDAP integration configuration file: atlassian-user.xml. There should be an additional option to encrypt the password that accesses the LDAP instead of storing it as plain text only in the configuration file.

Encrypted storage of passwords is saver than storing them in plain text. The security risk introduced is bigger when the password is used to access the company LDAP server. A system LDAP account allows for unlimited user authentication tries. This is heaven for hackers wanting to crack passwords. Anonymous access to the LDAP server is worse because hackers then only need to know the location of the server to start there password cracking.

While encrypting passwords adds a small level of security, it's only of limited value.

Both the algorithm and secret used to encrypt the password must necessarily be stored with Confluence, so all the data an attacker needs to retrieve the encrypted password will be there, just one extra step away. As such, encryption only protects you in two circumstances: protecting from casual attackers who don't want to do the small bit of extra work required to decrypt the password, and protecting passwords recovered from backups (provided we configure a second location where the encryption secret is stored, and that is backed up separately).

Alternatively, we could go the apache-ssl route and have you type in a password every time Confluence starts up...

Note, I'm not saying that encryption is a bad idea. I think this is something that we should implement, if only because it's mildly embarrassing that we haven't already. It's just in many ways a false sense of security.

Well written Charles. A very clear description of what encryption will add.

There is a saying in Dutch which translates to something like:

Occasion makes the thieve.

It means, the easier it is to do something illegal, the more likely it is someone will be tempted into doing it. So even a small extra step can make a lot of difference.

The article below addresses the problem:

http://websphere.sys-con.com/read/393364.htm

It might help as a starting point for the solution,

Kind regards,

Erik

Having been on the other side of this, and tried to secure the startup of appservers, I can appreciate both the need for this kind of mechanism, and Charles' observation (which was exactly the conclusion we drew).

There's more than one way to approach this problem, though. May I suggest allowing passwords to be supplied as JVM -D variables, which can be set within startup scripts and added to JAVA_OPTS?

This allows the encryption/obfuscation to be outsourced: the customer can then use their own choice of encryption/obfuscation, and make it just as involved and secure as they choose. It could even be feasible to store the passwords on another machine altogether, and retrieve them via an SSL-encrypted request on startup, to keep it off the local drives completely.
I do realise that this is still a case of moving the lump, as the means for retrieving the password still has to be available within the startup script. However, it looks to me like a low-cost means of giving customers the means to make it as tricky as they wanna, compared to the effort of building something solid for decrypting entire config files directly into Confluence's startup process.

I know from experience how frustrating it is when a vendor's product locks out even this option, especially when trivial obfuscation (ROT-13, anybody?) is sufficient to pass an internal audit, and plaintext config files just aren't really an option in large financial contexts.

We will consider adding this feature into a future release. We estimate that this is 1-2 weeks worth of work, but are prioritizing it against other high priority feature requests.

If you're interested to know how we decide on which features to implement, please read this:
http://confluence.atlassian.com/display/DEV/Implementation+of+New+Features+and+Improvements

I must disagree with Charles Miller, password encryption with a strong algorathm is an absolute requirement for our organization and I believe it does, in fact, provide security. The issue I take with him is the statement "algorithm and secret used to encrypt the password must necessarily be stored with Confluence", the encryption algorithm should be stored in complied code, and there is no reason why the software design could not allow for separating the secret from the actual encrypted password (i.e. xml file has the secrete and the DB has the password). Ok, before you call me out, I realize something else would be necessary for the database user, but, they could also be in seperate xml files, or a properties file with an obscure name. This should mitigate most if not all of the possiblity of the password being discovered by hackers.