A few basic notes on Oracle Database Administration.

Thursday, March 27, 2008

Exposed Password in Data Pump

I was just looking at a production Data Pump today with a text exposed 'system/password'. I was startled.

Then I remembered that in the last shop Data Pumps involved
  1. Temporarly change the system user password
  2. Run the Data Pump with the temporary password in plain text
  3. Changing the password back.
Now that I think of it, the one involving all that changing is only slightly better than what I saw today.

Does anyone have a suggestion for running Data Pump with a modicum of security? I had no say in the last shop. Here I may not prevail, but at least I'm in a position to make a suggestion if I have one.

Does the solution involve something with a password protected parameter file? Or? Thanks in advance for any suggestions offered.

8 comments:

jason arneil said...

I have just checked a datapump export. I do not see what you see:

Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning, Real Application Clusters and Data Mining options
Starting "SYSTEM"."SYS_EXPORT_SCHEMA_01": system/******** schemas=itbm directory=dumpdir dumpfile=itbm_080326b.dmp
Estimate in progress using BLOCKS method...

Is this where you see the password? Are you on a different verson?

girlgeek said...

What I saw was the command file in plain text of the form
expdp scott/tiger directory=dmp tables=emp

When the job actually runs the log obscures the password and in the log you get what you reported in your comment:
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Produc
tion
With the Partitioning, OLAP and Data Mining options
Starting "SCOTT"."SYS_EXPORT_TABLE_01": scott/******** directory=dmp tables=emp

But the job was submitted with a text file containing the exposed password.

I hope that that clarifies my concern. Thank you for responding

palmercabel said...

We use a unique user for performing exports and only grant exp_any and connect to this user as well as time/location constraints in the profile. Anyone seeing this user/pw has limited access.

If we need to import a privileged user account is used by a trusted (read: senior DBA) person.

We're also looking into piping the output of DP through encryption and running the job as a java proceedure through the scheduler. This alternative is appealing to us because no access credentials are shown in the file system.

HTH

Dan Norris said...

Hi Claudia,

If you're talking about seeing the password on the command line with a "ps" command or equivalent, then consider using the parfile= argument to expdp just like back in the exp days. Then put the u/p in the parfile to hide it from those that shouldn't see it. Make sure that the parfile you use has proper OS privs to protect it from prying eyes too.

girlgeek said...

Thank you all. I think that Dan's suggestions about protecting the par file are the simplest path. However, Palmer gave me some very interesting suggestions about creating a special user. I will make the appropriate changes to my new charges (databases).

Again, thank you all a million for your help.
-Claudia

Database Diva said...

Pardon me if I failed to see the obvious, as I sometimes have trouble finding the milk in the refrigerator (usually because I forgot I was looking for milk), but why not use an OS authenticated account for your exp and expdp jobs? That way your credential is merely a /. That is how we get around the issue.

Shony said...

Different options explained in this link
http://www.acehints.com/2011/07/how-to-hide-oracle-passwords-sqlldr.html

Shony said...

More options explained in this link
http://www.acehints.com/2011/07/how-to-hide-oracle-passwords-sqlldr.html