Encryption / Encryption and encryption of passwords in .properties files using Talend data integration

Question

One of the suggested ways to start tasks is to save context parameters in property files. Like this:

# #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 

It is very simple and useful, but the problem is that the passwords are kept clear.

So, I am looking for ways to easily encrypt. Here are two very complex questions that have already been discussed in the stack overflow on password encryption technique:

• Encrypt passwords in configuration files
• Password protection in the properties file

But they are native Java, and I'm looking for better Talend integration. I already tried different ways of working in Talend:

• Simple obfuscation using base64 password encoding
• Using tEncrypt and tDecrypt components from fake
• Using Jasypt ot JavaXCrypto librairies
• Using pwdstore from the forge

All of these techniques are described in a tutorial (in French, sorry), explaining how to encrypt passwords in Talend

But another problem arises: the keys used for encryption / encryption are always clear, so if you know good ways to solve this problem, I will be happy to experiment with it.

Answer 1

In essence, everything that an application can access can be achieved by someone who enters the system / gains control of the application. Even if you use obfuscation (for example, base64 or more advanced) or real encryption where keys are available (even if they can also be confused).

Thus, essentially, there is no good enough way to do what you are trying to do and even worse: it simply cannot exist.

So what are you doing instead?

1. Restrict rights

MySQL_Login=root is a big problem ... an application compromise will immediately compromise the database (and its data).

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

It really needs to be done and quite easy to achieve.

2. Separate user and administrator access

If some things are necessary only after interacting with the user, you can use the secrets provided by the user (for example, a user password can give a hash, and this can be processed and get a key that is not always present in the application or configuration files).

You can use this for example. to separate permissions at two levels: the regular user level, which has only minimal rights to make the application work for the average user (but, for example, does not have application control rights that allow you to control the application itself), and use the saved secrets so that the user leaves The key is outside the application until the administrator has included the administrator in the application.

This is rarely done honestly, and all is easy.

But even with all that you essentially need to consider access to, for example, the database will be compromised if the application is compromised.

That is why data, such as the application user password, should not (should not) be stored in the database without proper precautions.