This was the case in 1.4 right? 
At a minimum we need to doc this so people know to control access to this file

This page shows how this could work:
http://wiki.jboss.org/wiki/EncryptingDataSourcePasswords

But at the end, when the password to encrypt is stored with in a Java class, it is only obsfuscating the password for the casual lurker. Those that really want to get access to the db via that password and access to RHQ will also be able to read that above Wiki page ...

We discussed not to implement it, as it is security by obscurity and rather document the behaviour and to secure access the rhq-server.properties file.

Documented.

Reopening this, so we can address it in a future release.

Not going to make the 1.1 release

This bug was previously known as http://jira.rhq-project.org/browse/RHQ-227

I think we need to avoid doing anything if all we are going to do is implement "security by obscurity" which everyone knows is worse than no security because it lulls people into a sense of "false security".

rhq-server.properties needs to be locked down by the people that install the software.

Mazz, the idea is to make it harder for casual viewers of the rhq-server.properties file to immediately have access to the RHQ database, i.e. an extract hoop for someone to jump through which also may indicate to them they are doing something they shouldn't. Somebody determined to attack the system will still be able to gain access to the db if they have read access to the rhq-server.properties but obfuscating the password will prevent casual users from wondering into the RHQ database just because they can.

I'm changing the title of this jira to make it clearer we're only going to support obfuscation.

First cut is in a32db89465af384df8d30b3667f4f545d9893105 in master

Additional fix in 1e8fb58

Release note:

from RHQ 3.0.0.B05 on passwords for db access will always be encrypted when installing the server. The encrypted password is stored in bin/rhq-server.properties in the property
rhq.server.database.password

If the database password is upgraded, it also needs to be changed in this property.
To generate a new password, the provided scripts $RHQ_SERVER_BIN/generate-db-password.{sh,bat}
can be used by giving the db-password as argument like this:

$ bin/generate-db-password.sh test
Encoded password: 5..6b8b45e01...e

> $ bin/generate-db-password.sh test

Passing the password as a command-line arg has a couple security issues:

1) Someone looking over the user's shoulder could see the password.
2) Someone could run "ps" and see the password.

I'd suggest adding support to the script for reading the password from stdin, e.g.:

if [ $# -eq 0 ]; then
    read -p "Enter the DB password: " -s DB_PASSWORD
    
    # 2) may be an issue here too - depends how you're encrypting the password
    # encrypt $DB_PASSWORD     
fi

(In reply to comment #17)
> > $ bin/generate-db-password.sh test
> 
> Passing the password as a command-line arg has a couple security issues:
> 
> 1) Someone looking over the user's shoulder could see the password.
> 2) Someone could run "ps" and see the password.
> 
> I'd suggest adding support to the script for reading the password from stdin,

Reading the password from stdin won't fix 2) with the current implementation as it is just passed into the JVM and would still be exposed on the command line.

There are a couple ways around this: 

 2a) Use a Java class to do the prompting
 2b) Offer the option to store the plain-text password in a file and have a Java class read the file and delete it when it is done

In either case, it will require the plain-text password to be handled in the JVM and not within the shell/command environment.

Of course, this is a common issue with password handling.  As the process is short lived, it has become an acceptable practice to just pass it in as an argument and simply realize the associated security risk.  An alternative would be nice though for use within those untrusted environments.

Windows bat script fix in b0140c2

QA Verified.

Moving this back to ON_QA as there's a few more tests I want to consider.

QA Verifying.  I think it is safe to close this out at this point.

Mass-closure of verified bugs against JON.