This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 535601 - (RHQ-227) Obfuscate DB password stored in
Obfuscate DB password stored in
Product: RHQ Project
Classification: Other
Component: Core Server (Show other bugs)
All All
medium Severity medium (vote)
: ---
: ---
Assigned To: Heiko W. Rupp
Corey Welton
: Improvement
Depends On:
Blocks: 577033
  Show dependency treegraph
Reported: 2008-04-03 12:26 EDT by Ian Springer
Modified: 2013-08-05 20:33 EDT (History)
7 users (show)

See Also:
Fixed In Version: 2.4
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-08-12 12:51:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:

Attachments (Terms of Use)

  None (edit)
Description Ian Springer 2008-04-03 12:26:00 EDT

Comment 1 Charles Crouch 2008-04-07 18:58:28 EDT
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
Comment 2 Heiko W. Rupp 2008-04-11 09:07:10 EDT
This page shows how this could work:

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 ...
Comment 3 Heiko W. Rupp 2008-04-14 10:13:15 EDT
We discussed not to implement it, as it is security by obscurity and rather document the behaviour and to secure access the file.
Comment 4 Heiko W. Rupp 2008-04-14 10:28:41 EDT
Comment 5 Ian Springer 2008-05-02 11:22:17 EDT
Reopening this, so we can address it in a future release.
Comment 6 Greg Hinkle 2008-07-10 14:53:03 EDT
Not going to make the 1.1 release
Comment 7 Red Hat Bugzilla 2009-11-10 16:01:22 EST
This bug was previously known as
Comment 9 John Mazzitelli 2010-03-22 17:23:39 EDT
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". needs to be locked down by the people that install the software.
Comment 11 Charles Crouch 2010-03-22 22:15:07 EDT
Mazz, the idea is to make it harder for casual viewers of the 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 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.
Comment 14 Heiko W. Rupp 2010-03-26 08:51:59 EDT
First cut is in a32db89465af384df8d30b3667f4f545d9893105 in master
Comment 15 Heiko W. Rupp 2010-03-26 09:31:04 EDT
Additional fix in 1e8fb58
Comment 16 Heiko W. Rupp 2010-03-26 10:31:28 EDT
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/ in the property

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/ test
Encoded password: 5..6b8b45e01...e
Comment 17 Ian Springer 2010-03-26 10:42:37 EDT
> $ bin/ 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     
Comment 18 Larry O'Leary 2010-03-26 11:08:06 EDT
(In reply to comment #17)
> > $ bin/ 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.
Comment 22 Heiko W. Rupp 2010-03-29 08:23:13 EDT
Windows bat script fix in b0140c2
Comment 25 Corey Welton 2010-03-30 10:28:14 EDT
QA Verified.
Comment 26 Corey Welton 2010-04-01 10:39:29 EDT
Moving this back to ON_QA as there's a few more tests I want to consider.
Comment 27 Corey Welton 2010-06-02 09:41:49 EDT
QA Verifying.  I think it is safe to close this out at this point.
Comment 28 Corey Welton 2010-08-12 12:51:21 EDT
Mass-closure of verified bugs against JON.

Note You need to log in before you can comment on or make changes to this bug.