RE: Risk of knowing password hash value (Was: OEM permissions)

Not really... you could easily compile a list of passwords and their associated hashes. Once this is done, it's just a simple matter of matching the hashes.

-----Original Message-----
Jared Still
Sent: Tuesday, December 23, 2003 1:24 PM To: Multiple recipients of list ORACLE-L

As long Oracle can manage to keep its modified DES algorithm secret, this should make it somewhat difficult to crack passwords in the manner that can be done with unix passwords.

It could still be done, but the time required would make it just too time consuming IMO.

Jared

On Tue, 2003-12-23 at 09:44, Stephen.Lee_at_DTAG.Com wrote:
>
> When I brought the issue up, I didn't know if one could in fact maliciously
> use that info. And, as I originally stated, it was something I had not
> tried. But paranoia (healthy, I think) dictates there's gotta be a way.
> When one looks at the Unix password world which brought about the necessity
> for a shadow file, and the evils of the old NIS where ypcat was available,
> you have to wonder why allowing access to the encrypted passwords for Unix
> is considered a dumb thing to do, but somehow in Oracle it would be an OK
> thing to do. I'm inclined to say that Oracle restricted access to the views
> and underlying tables for reasons more substantial than just to frustrate
> non-privileged users. And, if I'm not mistaken, the specs on the views are
> "subject to change without notice". I have enough to do without trying to
> stay on top of every stinkin' view in Oracle in every stinkin' release and
> how one might use that view in naughty ways.
>
> For what it's worth, after haggling and fussing, we were able to compromise
> on this. We haven't tried to tear each of these apart to see how it might
> be abused. If any of you have some warnings to provide, please do!
>
> -- Must run this as SYS
>
> create role DBARTISAN_USER_ROLE;
>
> grant SELECT on SYS.V_$PROCESS to DBARTISAN_USER_ROLE;
> grant SELECT on SYS.V_$SESSION to DBARTISAN_USER_ROLE;
> grant SELECT on SYS.V_$LATCH to DBARTISAN_USER_ROLE;
> grant SELECT on SYS.V_$LATCHNAME to DBARTISAN_USER_ROLE;
> grant SELECT on SYS.V_$LATCHHOLDER to DBARTISAN_USER_ROLE;
> grant SELECT on SYS.V_$LOCK to DBARTISAN_USER_ROLE;
> grant SELECT on SYS.V_$SESSTAT to DBARTISAN_USER_ROLE;
> grant SELECT on SYS.V_$MYSTAT to DBARTISAN_USER_ROLE;
> grant SELECT on SYS.V_$SYSSTAT to DBARTISAN_USER_ROLE;
> grant SELECT on SYS.V_$STATNAME to DBARTISAN_USER_ROLE;
> grant SELECT on SYS.V_$ACCESS to DBARTISAN_USER_ROLE;
> grant SELECT on SYS.V_$FILESTAT to DBARTISAN_USER_ROLE;
> grant SELECT on SYS.V_$ROLLNAME to DBARTISAN_USER_ROLE;
> grant SELECT on SYS.V_$ROLLSTAT to DBARTISAN_USER_ROLE;
> grant SELECT on SYS.V_$SGA to DBARTISAN_USER_ROLE;
> grant SELECT on SYS.V_$PARAMETER to DBARTISAN_USER_ROLE;
> grant SELECT on SYS.V_$ROWCACHE to DBARTISAN_USER_ROLE;
> grant SELECT on SYS.V_$LIBRARYCACHE to DBARTISAN_USER_ROLE;
> grant SELECT on SYS.V_$INSTANCE to DBARTISAN_USER_ROLE;
> grant SELECT on SYS.V_$DISPATCHER to DBARTISAN_USER_ROLE;
> grant SELECT on SYS.V_$SQLAREA to DBARTISAN_USER_ROLE;
> grant SELECT on SYS.V_$SQLTEXT to DBARTISAN_USER_ROLE;
> grant SELECT on SYS.V_$SQLTEXT_WITH_NEWLINES to DBARTISAN_USER_ROLE;
> grant SELECT on SYS.V_$OPEN_CURSOR to DBARTISAN_USER_ROLE;
> grant SELECT on SYS.V_$PQ_SYSSTAT to DBARTISAN_USER_ROLE;
> grant SELECT on SYS.V_$SGASTAT to DBARTISAN_USER_ROLE;
> grant SELECT on SYS.V_$SHARED_SERVER to DBARTISAN_USER_ROLE;
> grant SELECT on SYS.V_$DATAFILE to DBARTISAN_USER_ROLE;
> grant SELECT on SYS.V_$TABLESPACE to DBARTISAN_USER_ROLE;
> grant SELECT on SYS.V_$SESS_IO to DBARTISAN_USER_ROLE;
> grant SELECT on SYS.ALL_OBJECTS to DBARTISAN_USER_ROLE;
> grant SELECT on SYS.DBA_ROLLBACK_SEGS to DBARTISAN_USER_ROLE;
> grant SELECT on SYS.PRODUCT_COMPONENT_VERSION to DBARTISAN_USER_ROLE;
> grant SELECT on SYS.DBA_EXTENTS to DBARTISAN_USER_ROLE;
>
> grant DBARTISAN_USER_ROLE to USER_WE_DONT_LIKE;
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: <Stephen.Lee_at_DTAG.Com
> INET: Stephen.Lee_at_DTAG.Com
>
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Jared Still
  INET: jkstill_at_cybcon.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Norris, Gregory T [ITS]
  INET: gregory.t.norris_at_mail.sprint.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).