Tom - a full export is being provided to a new vendor so they may "do something" with it. A concern has been raised that the passwords for all the important schemas will be available in the export - and therefore compromise security of the original production database. Is there a way to change the user passwords in the export? The only idea suggested is to re-import it into a dev database, change all the passwords and re-export it, which seems like it would take a lot of time. The production passwords cannot be changed because it is ..well.. production. Any suggestions?
Thanks,
Dc.
In the export dump file, you will find:
$ grep --text 'CREATE USER' expdat.dmp
CREATE USER "OUTLN" IDENTIFIED BY VALUES '4A3BA55E08595C81' TEMPORARY TABLESPACE "TEMP_NEW" PASSWORD EXPIRE ACCOUNT LOCK
CREATE USER "TSMSYS" IDENTIFIED BY VALUES '3DF26A8B17D0F29F' DEFAULT TABLESPACE "USERS" TEMPORARY TABLESPACE "TEMP_NEW" PASSWORD EXPIRE ACCOUNT LOCK
CREATE USER "ANONYMOUS" IDENTIFIED BY VALUES 'anonymous' DEFAULT TABLESPACE "SYSAUX" TEMPORARY TABLESPACE "TEMP_NEW" PASSWORD EXPIRE ACCOUNT LOCK
CREATE USER "OLAPSYS" IDENTIFIED BY VALUES '3FB8EF9DB538647C' DEFAULT TABLESPACE "SYSAUX" TEMPORARY TABLESPACE "TEMP_NEW" PASSWORD EXPIRE ACCOUNT LOCK
CREATE USER "MDDATA" IDENTIFIED BY VALUES 'DF02A496267DEE66' DEFAULT TABLESPACE "USERS" TEMPORARY TABLESPACE "TEMP_NEW" PASSWORD EXPIRE ACCOUNT LOCK
CREATE USER "SYSMAN" IDENTIFIED BY VALUES '447B729161192C24' DEFAULT TABLESPACE "SYSAUX" TEMPORARY TABLESPACE "TEMP_NEW"
CREATE USER "MGMT_VIEW" IDENTIFIED BY VALUES '4F538DF5F344F348' TEMPORARY TABLESPACE "TEMP_NEW" PASSWORD EXPIRE ACCOUNT LOCK
which means the passwords won't be there - BUT - they could easily find a password cracker with a 'library' of commonly used ones and probably brute force many or most of your passwords (the use of so called rainbow tables will make it even faster - for usernames that are 'common' like sys and system, they can just compare hashes and if you use a password that someone has and is in the rainbow table, it'll instantly give them that password)
However, to that I say "so what" in your case.
You just gave them the entire database without ANY ACCESS CONTROL - they'll log in as sysdba and see everything. So, who cares if they have your passwords.
Meaning - I don't think you should do this, this is not a reasonable request. They should request just the data they need, period. And you would provide just the data - table exports - period.
Just my two cents worth, you should not let your hashes out, they can be cracked brute force.