DSXchange

Hi Friends,

I have observed a difference in DS 7.5 and DS8.1 server edition. When I double click on a finished job in director in DS 7.5 there we can see the password in encrypted format.

But at the same time when I double click on a finished job in director in DS8.1 server edition I can the see password like ********** format, But I wanted to see the password in encrypted format can anyone help me if I have to change any settings in DS 8.1


Thanks

I am just curious! What you are trying to do with the encrypted password?

ETLJOB wrote:I am just curious! What you are trying to do with the encrypted password?

I actually wanted the testing team to use this encrypted password.


DS 7.1 director shows as
SOURCE_DB_P=D1.WORLD
SOURCE_DB_USER_P=D_04
SOURCE_DB_PASSWORD_P=L5J@I9V1?9KL0?4IE9N<@OA7
ODS_DB_P=D1.WORLD
ODS_DB_USER_P=D_05
ODS_DB_PASSWORD_P=LEJ@1:VHN9BN0FEI49J52KI6B<<




DS 8.1 shows as

Current job parameters:
SOURCE_DB_P=D1.WORLD
SOURCE_DB_USER_P=D_04
SOURCE_DB_PASSWORD_P=********
ODS_DB_P=D1.WORLD
ODS_DB_USER_P=D_05
ODS_DB_PASSWORD_P=********

The one in bold makes a difference can anyone help me how to achieve this in DS8.1 server edition

what i am curious is what sense does the encrypted value make unless you are able to decrypt it which i guess is not possible

zulfi123786 wrote: which i guess is not possible

never say never

Yes, the encryption is not strong and certainly not meant to be any kind of crack proof - any frequent readers here should remember it has already been "cracked"... more than once.

You can compare encrypted values across jobs to ensure the original values are indentical, other than that I'm not sure how they can be "used" by anyone.

I actually want to give this encrypted password to the testing team to use as a parameter for the job. Instead of giving the original password. We want to restrict them to access oracle table access directly.

This is possible in DS 7.5 server edition, where as in DS 8.1 edition it is throwing out only *******(asteric symbols) instead of encrypted pwd. Please can anyone throw some light as how to generate a encrypted pwd in DS8.1 server edition instead of asteric symbols(******).

This was seen as a security breach and tightened.

There is a proper, rigorous way to manage passwords. Use that.

ray.wurlod wrote:This was seen as a security breach and tightened.

There is a proper, rigorous way to manage passwords. Use that. ...

Hi Ray,

Thanks for the reply, But can you please help me with procedure to write a pwd in encrypted format using DS 8.1

There are literally zillions of different encryption algorithms out there, from simple substitution through to 128-bit private key encryption. How strong do you need the encryption to be? Do you need decryption as well, or are you happy simply comparing the encrypted forms? In the latter case you can go with "one way encryption".

ray.wurlod wrote:There are literally zillions of different encryption algorithms out there, from simple substitution through to 128-bit private key encryption. How strong do you need the encryption to be? Do you nee ...

I just need a simple subtitution of original pwd,

Thanks

Then a simple Convert() function will do it for you if you are happy with character-by-character substitution.

If you want each character replaced by two or three (or more) characters you will need to create a routine, but it's not a difficult one to write. For example, if your domain of password characters is only "ABCDE" then would do the trick for two-character substitution.

Hi Ray,

I want the first original password to be converted into encrypted and then use this encrypted as a password for the jobs for connecting to database by assigning to a parameter.

does this work If I use convert()?

You would have build something to first encrypt them and then job control to decrypt them on the fly when it sets the value and runs the job. None of this will help with running from the GUI and everything would be in clear text in the job's log.

You need to rethink this 'requirement', find some other way to solve your issue. Perhaps just by having someone (you?) set the encrypted value via the Director after the job is migrated to the other environment.

Try using parameter sets. They can be very helpful in this regards. When I setup a parameter set, I have different value files setup for Dev, Test and Production. When the user runs the job, all they have to do is select the correct environment and then over-ride any other parameters they need to change. Passwords are already filled in correctly.