Recommendations for Encrypting / Decrypting Strings in Vaadin Spring Boot

Hey there.
I am using Vaadin 23 with SB 2.7, and before going into production my IT asks that I provide the SB Database Credentials in an external file, encrypted.

So I already moved the relevant rows from application.properties as described here:
https://vaadin.com/docs/v23/security/advanced-topics/external-configuration/#import-configuration-from-external-file

In that context I most often I have read now about Jasypt:
http://www.jasypt.org/

What are you guys using, what are your experiences, and have you any other recommendations or hints?
Thanks in advance :slightly_smiling_face:

I’m storing them in environment variables - nothing really fancy

If an attacker has gained access to your system and can read environment variables, he’s probably also skilled enough to encrypt the password you created with jascrypt :sweat_smile:

probably :smile:

but well, as it’s kind of “demand” from our IT I have to…

Security by obscurity, I see what the goal of your IT is :grimacing:

@quirky-zebra That isn’t a very good assumption. It can be a simple misconfiguration. Storing in the environment variables can then be leaked to the users history or in a shell script. It’s not a bad idea for dev or for something like a hardened system, but like everything else - it depends on the scenario.

@MadMojo - I’d recommend using something like a password vault (Hashicorp Vault, AWS KeyStore) or something like that to store database credentials. Using Vault allows you to also leverage Spring’s Configuration tech stack to do auto password rotation and managing crypto strings as well.

The same holds true with the pseudo encryption and de-encryption of passwords - but I totally understand your point tho!

Well… :smile:
The moment the application plus it’s VM is going into production sooner or later, “us developers” have to take the hands of that VM :slightly_smiling_face: We still may read the log files and perhaps also see the DB content at a mirrored DB, but that’s it. Deployment of new versions via support ticket. No write access to anything.
And from data centers point of view they would like that we don’t even know the DB credentials, therefore encrypted, which is … well … kinda ridiculous as e.g. it’s me encrypting the credentials as there is no tool in this context which “they” simply start at the moved properties file, encrypt, and the Vaadin Spring Boot app will still be able to decrypt.

I’m sorry for you, is probably the only thing I can say without insulting someone :sweat_smile: excuse me we have 2023 and Dev(Sec)Ops is a thing

FunFact: Our company is hiring DevOps already years ago. And on internal test systems I act same way only it’s not called DevOps :slightly_smiling_face:
But the production servers, seperate network, is kind of the Holy Grail :slightly_smiling_face:

Yeah of course those VMs and Apps shall not be touched, once in production, as clients may depend on them. But the clients may also depend on responsible support from me and my work mates.

Hehe ok, why I’m telling that here, I should tell it “them” :smile:

Sometimes it’s good to rant :sweat_smile: but totally yeah, that should change. Just an example: Log4Shell and other stuff has to be fixed literally immediately and not after the ticket to deploy was escalated after 5 days of waiting time :sweat_smile:

Yeah exactly :slightly_smiling_face:
And thanks for listening :wink: