2

I am currently formulating security best practices and requirements for ongoing Java software development in my department and have settled with a recommendation of using the Jasypt framework for encryption/decryption of service account credentials stored in application property files on the system. The general parent requirement from our Cyber Security team is that confidential data at rest must be protected through encryption, however there are no specifics provided on proper key management.

The appropriate scheme provided by Jasypt is to use a PBE algorithm that takes a secret passphrase as input and uses this to decrypt protected information in application properties files. You can provide the secret passphrase in a number of ways, and the most appropriate universal way that seems to balance convenience, supportability and security is to obtain this secret through a runtime user environment variable.

Setting a global environment variable is clearly not secure, and our system administrator claims we can't set it at the user level because he claims it would only be loaded as part of the bash profile, and that would mean the application would require being launched from a shell, which precludes it being run as a daemon process.

I was thinking that I could execute the application from a bash shell script where the necessary environment variable is set within the scope of the script before the Java application command is executed. I could then read protect that shell script file only to the runtime user of the daemon process.

The OS in question is RHEL 6.5 running on virtualized servers within our private intranet.

My question is, are there any noticeable exploits here where an attacker could derive the environment variable value somehow? For instance, by running bash history, grepping running processes, peeking at shared memory, etc?

In general are there are any major noticeable flaws with this approach?

  • 1
    If your application property files are only readable by the daemon user, and the encryption key is readable by the daemon user, then this sounds like it's just security through obscurity and mostly pointless. – AndrolGenhald Jan 4 '18 at 15:07
  • @AndrolGenhald Eventually even if I externalize this passphrase from the system, I will need some kind of secret to authenticate to the outside source for the secret, leading me to the same problem. I kind of see the point, however one could make the argument that since computers are fundamentally deterministic systems that all encryption schemes are merely complicated means of obfuscation. – maple_shaft Jan 4 '18 at 15:33
  • What are you trying to accomplish?. Protect user credentials or reduce user credential exposure?. I think JASYPT help only to reduce exposure. Thanks – Anou Oct 31 at 16:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.