| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Risk of knowing password hash value (Was: OEM permissions)
No. Two different users with the same password would have different hash
values.
So you would have to loop through a "dictionary list" for each user within your local database. Once you got a match, then you could logon to the target database with that user/password combo.
-----Original Message-----
Sent: Tuesday, December 23, 2003 3:29 PM
To: Multiple recipients of list ORACLE-L
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). "This information in this e-mail is intended solely for the addressee and may contain information which is confidential or privileged. Access to this e-mail by anyone else is unauthorized. If you are not the intended recipient, or believe that you have received this communication in error, please do not print, copy, retransmit, disseminate, or otherwise use the information. Also, please notify the sender that you have received this e-mail in error, and delete the copy you received." -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Davey, Alan INET: Alan.Davey_at_encodasystems.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).Received on Tue Dec 23 2003 - 14:59:24 CST
 |
 |