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

You could conceivably do this, much like lopht or crack.

It would take a rather large password database, and a cracker with some intelligence. This is the same reason that unix now uses shadow passwords.

Jared

On Tue, 2003-12-23 at 12:29, Norris, Gregory T [ITS] wrote:
> 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).

-- 
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).