We need to hide any such "security-sensitive" information from scripts.
Is not allowed to store password in a clear-text in scripts.
Please note: we already have a TXMON.INI file which contains encrypted password. And I can program a simple tool which can decode that password but...
... the question is - how exactly to feed the "DB2 connect ..." command line with a decrypted password?
On UNIX/Linix I know - there is an ability to substitute a part of command line with StdOut from some application (using apostrophe char). So, on Linux it could sounds like this (this example command is not related to db2, is just to show an approach - instead of command enclosed in `` Linux shell inserts StdOut of a command inside a ``):
But I do not know - how to do it on Windows? Is it possible at all?
If yes - how exactly? If not - what other options we may have to solve this?
Note: is not ok to use PowerShell. Is only ok to use standard Windows CMD. Or even better to say - is only ok to use DB2CMD (which is a kind of wrapper over Windows CMD).
Note: is not ok to enforce user to enter password anytime script is running. Because in most cases scripts should run automatically without human assistance.
Note: is not ok to use ""db2 connect ..." command without credentials(!). Because a logged user credentials are not always match a correct database account. But however scripts should still works fine in such cases.
Write-access to script is denied by installer. Also it script itself is not in a "public" directory. So, I assume that should be enough for my case.
Note: the $(...) parameters are replaced by installed with actual values.
Here is example of encoded password: 2!cf1a8b63~MGBsqB7yZgvagDPpnfMq6Xh/RLP4ASyQx7LZdkdedxV+aRbWoZsA+Rsf7b0qt30rURz/v9fPXuW6jCPRkVJ3EB.
So, it has CRC-value and some random data.
The InstUtil.dll is a my dll with password decoding function.
I have looked on CPAU tool. Do not like it. It is not convenient for me.
Imagine - what would happen if customer will change password?! It would means that we have to re-encode all the jobs with CPAU tool. That is bad scenario for us.
I would prefer to read & decode password from existing INI file rather than encoding/encrypting lot of jobs with CPAU tool. Read&decode - I can do this with my tool (is just a couple of API calls) but question - how to submit password from a running program into a command line of "DB2 connect ..."?
Another problem with CPAU - it seems does not work. I can create a job file but it fail on job execution. So, I typed commands (as described in CPAU examples):
1st command works fine, 2nd command always do not work. :-\
So, tool is not suitable and is not working.
Please suggest other options.
0
Squarespace’s all-in-one platform gives you everything you need to express yourself creatively online, whether it is with a domain, website, or online store. Get started with your free trial today, and when ready, take 10% off your first purchase with offer code 'EXPERTS'.
The problem is that a script can be modified at any time to ECHO a decoded password parameter or any other sensitive information. Unless the script itself is protected from every user that can be a risk, there will not be anything that is hidden.
As long as it is understood that nothing is protected in the script, then a script is fine.
Tom
0
Dmitry_BondAuthor Commented:
Ya... but script is the easiest (and cheapest) way to do maintenance.
If not use a script then we have to invest a lot of resources into development of special maintenance application. We could not do it now...
Personnel on site is not so experienced to do ECHO for a password. Also, script file itself could be protected by security settings to disable write access to it. So, in this particular case is ok to still use a script in some places. Only need to hide a clear-text password somehow.
0
Dmitry_BondAuthor Commented:
Solution is not perfect but is match our needs and conditions.
Also match standard Windows functionality.
0
Question has a verified solution.
Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.
Open in new window
Write-access to script is denied by installer. Also it script itself is not in a "public" directory. So, I assume that should be enough for my case.
Note: the $(...) parameters are replaced by installed with actual values.
Here is example of encoded password: 2!cf1a8b63~MGBsqB7yZgvagDP
So, it has CRC-value and some random data.
The InstUtil.dll is a my dll with password decoding function.