1

I'm looking for a way to store encrypted text in a properties' file, and then decrypt it on the fly, something that allows something like:

  • Store password in encrypted form in properties' file
  • When Spring reads that property from a placeholder, it automatically decrypts it and loads the plain text value

After searching the web, all I found was Jasypt. I gave it a test run, and it does what I need, but it seems abandoned? (Last commit activity was 2 years ago).

So far, I've replaced Spring's PropertyPlaceholderConfigurer to detect encrypted values and to decrypt them before loading, and managed to get it working.

However, since it's security, I'm somewhat worried that rolling my own solution isn't the best way to do this. Are there any coding particulars I should be aware of when hosting my own encryption/decryption capabilities (even though I'm using Java's built-in functions underneath)? Or is it safer to go with a possibly abandoned, but well known project than to roll my own?

Thank you.

EDIT: edited to stay on-topic.

lv.
  • 446
  • 6
  • 18
  • Questions asking us to recommend or find a book, tool, software library, tutorial or other off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it. – Jim Garrison Jan 21 '16 at 17:21
  • Wouldn't it be possible to use hash codes for your passwords instead of encrypting them? – splash Feb 01 '16 at 15:55
  • No, because although the passwords must be protected in the property files, they must be sent in plain-text (e.g., I can't send the hash of the DB password to the DB). Since hashing is only one-way, I wouldn't be able to then use the passwords, hence the encryption choice. – lv. Feb 02 '16 at 10:02

1 Answers1

0

I can vouch for using Jasypt. It does what it's supposed to do, and multiple dev teams that I work with still use it in their applications.

Julian Egbert
  • 1
  • And there's no worries about lack of support, or Jasypt becoming out of date with any of the 3rd party software it uses (for example, ceasing to be compatible with the latest spring versions)? Or are your dev teams considering implementing the needed changes themselves if needed? – lv. Feb 02 '16 at 10:07