5

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:

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

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.

Community
  • 1
  • 1
MordicusEtCubitus
  • 703
  • 8
  • 10

1 Answers1

2

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.

  • Thanks for the answer. Indeed, login=root has been left for my test, I never use it in production. But it was a good point to underline. I will try the xor-ed case. I've given you the "accepted" answer so you will get the bounty before it expires, but I would have expected real use case that you had experimented. Thanks anyway. – MordicusEtCubitus Jan 11 '16 at 07:25
  • To get to the 2 levels of access: –  Jan 12 '16 at 13:23
  • User and admin as an example, but you can add more although it quickly becomes complex Get 1 password you store plainly to your database with the minimal rights among others, allow read acces to the users Create a second user/password for admin access. Now for every user with that right, add a column in the user table with the xor-ed admin passwd to the database and their own password hash". So whenever you application sees the password in plain text, it generates the admin password and stores it in the session to the database with admin rights for the session –  Jan 12 '16 at 13:31
  • As you see while active for one admin - even if for just a few seconds, the application will still know how to find that second password. So if the application is compromised, the attacker will still have a way to get access. With a bit more work. That's the reason very few bother with this ... –  Jan 12 '16 at 13:34