Our Security Department doesn’t want us to have JOSS web configuration file (oracle-db.properties) that contain the plain text password of the database that we are connecting to. I was told that I should retrieve the password from a JBOSS Password vault but am having difficulty trying to figure out how to do this and have posted a question to try and find out. (see Java/Spring: How to retrieve password from JBOSS vault )

I am considering whether storing the password encrypted password in the oracle-db.properties and using this AES-Encryption Algorithm shown here, https://howtodoinjava.com/java/java-security/aes-256-encryption-decryption/, to decrypt it (I use the encrypt procedure to determine the encrypted password to put in the oracle-db.properties file). I was thinking that, because the Secret key and salt are stored in the code, it is possible that the code can be reverse compiled to get these values. I was wondering what the pros and cons of this method vs retrieving the password from the JBOSS Vault (https://access.redhat.com/documentation/en-us/red_hat_jboss_web_server/5.3/html/installation_guide/vault_for_jws_) . Would adding the AES 256 to our application generally be sufficient for most companies?

CodePudding user response：

I was thinking that, because the Secret key and salt are stored in the code, it is possible that the code can be reverse compiled to get these values.

Correct. AES encrypting that password accomplishes almost nothing, and in fact makes things worse: It looks encrypted (because it is), and one would assume the persons doing the encryption wouldn't be so incredibly dense as to leave the key right there next to the password file.

Except that it is effectively right there (they'd have to decompile the class files but that's not difficult and cannot be made difficult), so you've created the wrong impression.

Your security team needs to give you threat models to work with, they can't just say "do not read password from file", because that is impossible. Why can you not do that? What avenue of attack do they want to mitigate?

Examples:

• I do not want a syadmin casually cat-ing that file and thus smearing the password all over their screen and in their terminal app's history buffers for anybody to just shouldersurf.

ANSWER: Just base64 it. Yes, it's not crypto at all, but at least it makes no bones about it: Folks will see its base64 and assuming they aren't idiots know that means the password is right there. But it's protected against shouldersurfing and 'accidental' recollection (where someone has seen it with their eyes and may therefore just remember it even if they don't intend to). Someone has to go out of their way to unbase64 it, and if the rules say you can't do that, at least you've now forced an employee to outright break rules and potentially be committing a crime.

• I'm afraid someone will hack the server just barely enough to make it read files and echo them to the hacker.

Then the base64 thing does nothing, nor does the AES plan (as they can also make your webserver cat its own jars and class files, probably). One solution can be that the script that starts the server reads the file (and is root-operated, running the server under a webserver account) - that script reads the password (thus allowing you to make that file owned by root and unreadable by the webserver account), passes it as argument or environment var. Of course, this requires that you consider the risk of leaking an env var as considerably lower than a text file. Which is certainly possible. Alternatively, the script can write the password in a plain text file readable by the webserver user, and the webserver will read it, then delete the file. This isn't common, but it shows the point of threat models: Once you know what you're fighting, you can come up with a plan and execute accordingly.

• I want to use JBoss Password Vault

That is not sensible security policy: That is not a threat model. JPV doesn't solve any of these problems, to boot.

• I want a hacker that gains full access to the box, including root and/or write-access for the webserver user to not be able to use that as a springboard to hack the DB.

This is impossible, if the security team tells you this is the threat they need you to mitigate, you can tell them to go fetch Harry Potter's magic wand, because without it, you can't deliver. The hacker can simply rewrite your own classes/jars into sending the password to the hacker's servers, for example. This is strongly indicative your security team doesn't know how to do their job: They think of risks no matter how unlikely and demand it is 'protected against' (not really a thing; you can reduce and mitigate, security isn't black and white) without considering threat models or tradeoffs.

Get them educated, or decide to lie to them. You can't win when they act like this otherwise. Go over their heads maybe and get the boss involved.

• I want a hacker that manages to obtain a clone of the entire disk to not be able to access the DB.

Doable, but tricky. One easy way is that the server won't know the password either and will boot in an admin-only-mode, where the admin types the db password into a form which then unlocks the server to run properly. The server can then retain this password in memory only, thus foiling any disk copies. Except, you better turn of swap or store that on a different disk!

If you don't want that manual action, there's TPM chips (windows/linux systems generally) or T2 (apple). I don't know of any java-accessible tools that can do this, or DBs that can. These kinds of algorithms require a challenge/response model, you can't just 'store a password' in these in a meaningful way.

Ask the security team for a budget of 80k or so. If they balk, well, they've learned something. Security is a game of tradeoffs.