Cipher/Encrypt and uncrypt passwords in .properties files using Talend Data Integration

Question

One suggested way to run jobs is to save context parameters in properties files. Like this one:

#
#Wed Dec 16 18:23:03 CET 2015 
MySQL_AdditionalParams=noDatetimeStringSync\=true 
MySQL_Port=3306   
MySQL_Login=root 
MySQL_Password=secret_password_to_cipher 
MySQL_Database=talend MySQL_Server=localhost

This is really easy and useful, but the issue with this is that passwords are saved in clear.

So I'm looking for ways to do easily ciphering. Here are 2 very insteresting questions already discussed in Stack overflow about password ciphering technics:

• Encrypt passwords in configuration files
• Securing passwords in properties file

But they are Java native and I'm searching for a better Talend integration. I've already tried different ways in my Talend jobs:

• Simple obfuscation using base64 encoding of passwords
• Using tEncrypt and tDecrypt components from the forge
• Using Jasypt ot JavaXCrypto librairies
• Using pwdstore routine from the forge

All these technics are described in a tutorial (in french, sorry) explaining how to crypt passwords in Talend

But another issue is encountered: keys used to cipher/uncipher are always in clear, so if you know good ways to address this point I'll be glad to experiment it.

Answer 1

Fundamentally, anything an application can reach can be reached by somebody breaking in into the system/taking over control of the application. Even if you use obfuscation (such as base64 or more advanced), or real encryption where the keys are available (even if they too might be obfuscated).

So essentially there is no good enough way to do what you seek to do and worse: it simply cannot exist.

So what do you do instead ?

1. Limit the rights

MySQL_Login=root is a big problem ... a compromise of the application will lead to an immediate compromise of the database (and its data).

So, limit the rights to what is absolutely needed for the application.

This should really be done and is quite easy to achieve.

2. Separate user and admin level access

If certain things are only needed after user interaction, you can use secrets provided by the user (e.g. a password of the user can give a hash and that can be xor-ed with and get you a key that's not always present in the application nor configuration files).

You can use this e.g. to separate out permissions in two levels: the normal user level which only has the bare minimal rights to make the application work for the average user, (but e.g. not the application management rights that allow managing the application itself), and use the secrets kept by the user to keep (pert of) the key outside of the application while there's no admin logged in into the administrative part of the application.

This is rarely done to be honest, nor all that easy.

But even with all that you essentially have to consider the access to e.g. the database to be compromised if the application is compromised.

That's also why data such as application user password should not (must not) be stored in the database without proper precautions.