Pete Finnigan's Oracle Security Forum


    
      
        Pete Finnigan's Oracle Security Forum
        (http://www.petefinnigan.com/forum/yabb/YaBB.cgi)
      

        Oracle Security >> Oracle Security >> Remove hashed password from DBA_USERS
        
(Message started by: Pete Finnigan on Oct 4^th, 2005, 2:25am)

Title: Remove hashed password from DBA_USERS
Post by Pete Finnigan on Oct 4^th, 2005, 2:25am

This follows on from comments in the orabf posting in the Security tools, but isn't really about the tools so I've started a new post here.

"A hacker should not have the password hashes in an ideal world....
So as you point out the need is to be able to protect the hashes. block access to SYS.USER$, DBA-USERS, SYS.USER_HISTORY$ ... also orapwd file, full exports, list files from sqlplus etc... "

I feel DBA_USERS is probably the most vulnerable here. When a DBA has someone investigating application issues who's requested access to V$SQL, V$STAT, V$SQL_PLAN, V$SESSION....it is too easy to simply give SELECT_CATALOG_ROLE.
I wonder, does the DBA_USERS view need to include the hashed password.
Oracle turned off default access to SYS objects for SELECT ANY TABLE. I think a similar option showing 'AAAAA...' in the password column for any user that isn't logged on as SYSOPER/SYSDBA would be an improvement (and by sowing a dummy value rather than removing the column, it shouldn't break too many things).

Title: Re: Remove hashed password from DBA_USERS
Post by Pete Finnigan on Oct 4^th, 2005, 9:00am

Gamyers,

I don't see the problem having hash passwords in the dba_users (or other views/tables) view. I would never give a developer who is investigating application issues access to production databases. Cloning a production database and removing users, changing passwords, etc seems the best solution to me. It's more work but better. Security is not just technical issues but also the way you organise the access to the database.

But if someone thinks that hashes are dangerous then he could try strong authentication like TCPS:

create user ivan identified globally as 'CN=Ivan Saez';

select * from dba_users where username='IVAN'
SYS on 04-OCT-05 at IVAN2 > /

IVAN 65 GLOBAL
OPEN
USERS TEMP 03-OCT-05
DEFAULT DEFAULT_CONSUMER_GROUP
cn=IVAN SAEZ

regards,

Ivan

Title: Re: Remove hashed password from DBA_USERS
Post by Pete Finnigan on Oct 5^th, 2005, 1:02am

" I would never give a developer who is investigating application issues access to production databases."

But that's where the problems are. The problem might be locks, disk contention etc. Things that simply won't happen in a duplicated database.
This is one of those areas where conflict and frustration arises, when you've got users complaining about issues and the DBA refusing to let developers at the problem. That's where the developers are tempted to leave 'backdoors' in the code so they can actually do their job without the DBAs throwing hissy fits.

Title: Re: Remove hashed password from DBA_USERS
Post by Pete Finnigan on Oct 5^th, 2005, 8:33am

Gamyers,

I know that problem: developers complaining about issues and that the dba is making their lifes miserable :-)
The relation dba-developers, dba-system administrator and dba-network administrator is always tense and the dba is always the bad guy.

Maybe you could ask Oracle about redefining dba_users to leave out the hashes. Maybe the are no consequences?

regards,

Ivan

Title: Re: Remove hashed password from DBA_USERS
Post by Pete Finnigan on Oct 6^th, 2005, 5:26pm

Hi Gary,

This is the second time I have written this. I wrote a reply last night and my ADSL line crashed whilst this post was sending and I couldn't get it back..:-(

So here goes. I like the ieda of removing the password hashes from the DBA_USERS view as it is the most common way to get them. Unfortunatly as you know they are also available from lots of other sources such as SYS.USER$, SYS.USER_HISTORY$, exports, file listings etc.

The problem with removing the password column from the view would be two fold. First does any existing functionality rely on it? - not that i can think of but there could be. The second issue would be would Oracle support you if you change a shipped view? - probably but i would not risk it in a live environment.

How could you change it? - first you could edit the view DBA_USERS itself - this most likely would leave you unsupported. You could simply return 'XXXXXX' as suggested. You could create a new view DBA_USERSX without the password column or rather as above returning 'XXXXXXXX' and then link to it by pointing the DBA_USERS public link at DBA_USERSX instead. Then you would need to ensure that no users had access to the real DBA_USERS.

Run my script [url http://www.petefinnigan.com/who_can_access.sql]who_can_access.sql[/url] to find out which users and roles can access the view.

Your other option is to take the same approach with the SELECT_CATALOG role and either revoke the select privilege on DBA_USERS or do as above and create a new role without the select. The problem is the original role cannot be dropped as its used by Oracle themselves and dropping it could break something.

Protecting the hashes is very worthwhile but as you begin to investigate who can get to them and through what mechanisms it becomes less easy to rectify the problem. Remember also that SELECT ANY DICTIONARY will give access as will SELECT ANY TABLE if the dictionary accessibility is not set correctly so you would need to protect these privileges as wel.

Also remember that the hashes are stored in a datafile that can be accessed with strings so all OS access remotely using the database as a conduit also needs to be tied down....

Stronger authentication is also an option as Ivan points out but its not a base option.

Maybe as you suggest Oracle should remove the password column from the base view! - someone want to raise it?

cheers

Pete