Re: Risk of knowing password hash value (Was: OEM permissions)
9.2.0.2 on Sun Solaris... and yes, I got the same encrypted password --- Michael Thomas [EMAIL PROTECTED] wrote: Hi, Okay. I'm almost a believer of this as a problem. How about 9.2.0.4 on RH9.3. 1) What does anyone/everyone get for my this query (my results shown): connect system/[EMAIL PROTECTED]; alter user scott identified by tiger; -- select password from dba_users where username = 'SCOTT'; PASSWORD F894844C34402B67 2) If you all get the same, then I'm concerned. Regards, Mike Thomas --- Yong Huang [EMAIL PROTECTED] wrote: Jared, I see you log out and log back in as SYSTEM to DB2. But how do you know the password for SYSTEM to log back in with after you change it? What if you don't log out? When I tried that (i.e. not logging out), I got ORA-1017. Yong Huang --- Jared Still [EMAIL PROTECTED] wrote: Environment: DB1: RH 8.0 with Oracle EE 9.2.0.4 DB2: Win2k SP3 with Oracle EE 9.2.0.1 SYSTEM user on each database initially have different passwords. __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Michael Thomas INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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). __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Rachel Carmichael INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
RE: Risk of knowing password hash value (Was: OEM permissions)
This is what I got, Oracle 8.1.7.4 on Sun Solaris (I dropped the user): Connected to: Oracle8i Enterprise Edition Release 8.1.7.4.0 - Production With the Partitioning option JServer Release 8.1.7.4.0 - Production SQL create user scott identified by tiger; User created. SQL select password 2 from dba_users 3 where username = 'SCOTT'; PASSWORD -- F894844C34402B67 SQL Scott Canaan ([EMAIL PROTECTED]) (585) 475-7886 Life is like a sewer, what you get out of it depends on what you put into it. - Tom Lehrer. -Original Message- rahul sharma Sent: Tuesday, December 23, 2003 1:14 AM To: Multiple recipients of list ORACLE-L 8.1.7 on win2000 SQL select password 2 from dba_users 3 where username = 'SCOTT'; PASSWORD -- F894844C34402B67 - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Tuesday, December 23, 2003 11:44 AM Hi, Okay. I'm almost a believer of this as a problem. How about 9.2.0.4 on RH9.3. 1) What does anyone/everyone get for my this query (my results shown): connect system/[EMAIL PROTECTED]; alter user scott identified by tiger; -- select password from dba_users where username = 'SCOTT'; PASSWORD F894844C34402B67 2) If you all get the same, then I'm concerned. Regards, Mike Thomas --- Yong Huang [EMAIL PROTECTED] wrote: Jared, I see you log out and log back in as SYSTEM to DB2. But how do you know the password for SYSTEM to log back in with after you change it? What if you don't log out? When I tried that (i.e. not logging out), I got ORA-1017. Yong Huang --- Jared Still [EMAIL PROTECTED] wrote: Environment: DB1: RH 8.0 with Oracle EE 9.2.0.4 DB2: Win2k SP3 with Oracle EE 9.2.0.1 SYSTEM user on each database initially have different passwords. __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Michael Thomas INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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: rahul sharma INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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: Scott Canaan INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
RE: Risk of knowing password hash value (Was: OEM permissions)
[EMAIL PROTECTED] . oraenv ORACLE_SID = [OLDNCS1] ? DEVL [EMAIL PROTECTED] sys SQL*Plus: Release 9.2.0.2.0 - Production on Tue Dec 23 08:30:45 2003 Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved. Connected to: Oracle9i Enterprise Edition Release 9.2.0.2.0 - 64bit Production With the Partitioning, Real Application Clusters, OLAP and Oracle Data Mining options JServer Release 9.2.0.2.0 - Production 08:30:51 SQL alter user scott identified by tiger; User altered. 08:31:01 SQL select password from dba_users where username = 'SCOTT'; PASSWORD -- F894844C34402B67 9202 on AIX5L. So much for 40 bit one way encryption ... Raj Rajendra dot Jamadagni at nospamespn dot com All Views expressed in this email are strictly personal. QOTD: Any clod can have facts, having an opinion is an art ! -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Jamadagni, Rajendra INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
RE: Risk of knowing password hash value (Was: OEM permissions)
Same here... SQL select password from dba_users where username = 'SCOTT'; PASSWORD -- F894844C34402B67 -Original Message- Michael Thomas Sent: Monday, December 22, 2003 10:44 PM To: Multiple recipients of list ORACLE-L Hi, Okay. I'm almost a believer of this as a problem. How about 9.2.0.4 on RH9.3. 1) What does anyone/everyone get for my this query (my results shown): connect system/[EMAIL PROTECTED]; alter user scott identified by tiger; -- select password from dba_users where username = 'SCOTT'; PASSWORD F894844C34402B67 2) If you all get the same, then I'm concerned. Regards, Mike Thomas -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Norris, Gregory T [ITS] INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
RE: Risk of knowing password hash value (Was: OEM permissions)
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: [EMAIL PROTECTED] INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
RE: Risk of knowing password hash value (Was: OEM permissions)
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, [EMAIL PROTECTED] 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: [EMAIL PROTECTED] INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
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, [EMAIL PROTECTED] 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: [EMAIL PROTECTED] INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (note EXACT spelling of
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. - Alan Davey Senior Analyst/Project Leader Oracle 9i OCA; 3/4 OCP w) 973.267.5990 x458 w) 212.295.3458 -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, [EMAIL PROTECTED] 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: [EMAIL PROTECTED] INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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
RE: Risk of knowing password hash value (Was: OEM permissions)
Ah, you're right... the username is taken into account when the password is hashed. Quite a few applications have forced usernames, however, so I'm still a bit uneasy. It's clearly not as bad as I thought, however. -Original Message- Davey, Alan Sent: Tuesday, December 23, 2003 2:59 PM To: Multiple recipients of list ORACLE-L 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. - Alan Davey Senior Analyst/Project Leader Oracle 9i OCA; 3/4 OCP w) 973.267.5990 x458 w) 212.295.3458 -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, [EMAIL PROTECTED] 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: [EMAIL PROTECTED] INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California--
Re: Risk of knowing password hash value (Was: OEM permissions)
Actually, the concatenated string of userid and password is hashed. So if
that is same, you got yourself the same hashed password.
Consider this:
SQL create user ABC identified by DEF;
User created.
SQL create user ABCD identified by EF;
User created.
SQL select password from dba_users where username in ('ABC','ABCD');
PASSWORD
--
016811C1486D026B
016811C1486D026B
They have the same password hash, even though the password is different.
It's a trick we use in auditing for security holes in the database.
HTH.
Arup
- Original Message -
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Sent: Tuesday, December 23, 2003 3:59 PM
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.
-
Alan Davey
Senior Analyst/Project Leader
Oracle 9i OCA; 3/4 OCP
w) 973.267.5990 x458
w) 212.295.3458
-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, [EMAIL PROTECTED] 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
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, [EMAIL PROTECTED] 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: [EMAIL PROTECTED] INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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
RE: Risk of knowing password hash value (Was: OEM permissions)
Very Nice. I didn't know how the 2 values were used within the hashing
algorithm.
I would have thought it was a little more complex.
-
Alan Davey
Senior Analyst/Project Leader
Oracle 9i OCA; 3/4 OCP
w) 973.267.5990 x458
w) 212.295.3458
-Original Message-
Sent: Tuesday, December 23, 2003 4:45 PM
To: Multiple recipients of list ORACLE-L
Actually, the concatenated string of userid and password is hashed. So if
that is same, you got yourself the same hashed password.
Consider this:
SQL create user ABC identified by DEF;
User created.
SQL create user ABCD identified by EF;
User created.
SQL select password from dba_users where username in ('ABC','ABCD');
PASSWORD
--
016811C1486D026B
016811C1486D026B
They have the same password hash, even though the password is different.
It's a trick we use in auditing for security holes in the database.
HTH.
Arup
- Original Message -
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Sent: Tuesday, December 23, 2003 3:59 PM
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.
-
Alan Davey
Senior Analyst/Project Leader
Oracle 9i OCA; 3/4 OCP
w) 973.267.5990 x458
w) 212.295.3458
-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, [EMAIL PROTECTED] 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
RE: Risk of knowing password hash value (Was: OEM permissions)
Looks like they're using VMS's algorithm. *That's* a shocker!
-Original Message-
Sent: Tuesday, December 23, 2003 3:45 PM
To: Multiple recipients of list ORACLE-L
Actually, the concatenated string of userid and password is hashed. So if
that is same, you got yourself the same hashed password.
Consider this:
SQL create user ABC identified by DEF;
User created.
SQL create user ABCD identified by EF;
User created.
SQL select password from dba_users where username in ('ABC','ABCD');
PASSWORD
--
016811C1486D026B
016811C1486D026B
They have the same password hash, even though the password is different.
It's a trick we use in auditing for security holes in the database.
HTH.
Arup
- Original Message -
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Sent: Tuesday, December 23, 2003 3:59 PM
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.
-
Alan Davey
Senior Analyst/Project Leader
Oracle 9i OCA; 3/4 OCP
w) 973.267.5990 x458
w) 212.295.3458
-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, [EMAIL PROTECTED] 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
Re: Risk of knowing password hash value (Was: OEM permissions)
Environment:
DB1: RH 8.0 with Oracle EE 9.2.0.4
DB2: Win2k SP3 with Oracle EE 9.2.0.1
SYSTEM user on each database initially have different passwords.
It goes something like this:
DB1:
select password from dba_users where username = 'SYSTEM';
Let's say the result is 'AC424SDK4398'
DB2:
Logon to DB2 as SYSTEM.
alter user SYSTEM identified by values 'AC424SDK4398';
create database link systemlink using 'DB1';
Logout, and log back on to DB2 as SYSTEM.
select count(*) from [EMAIL PROTECTED];
Works for me in this environment. DB2 is compromised.
HTH
Jared
On Mon, 2003-12-22 at 08:29, Yong Huang wrote:
Hi, Gregory,
I only have access to Oracle 9.2 on my laptop. Here's my test. I have ORCL and
AUX1 databases, the latter created by RMAN DUPLICATE some time ago. I logon
AUX1 as SYSTEM. Set SYSTEM password hash value to the same as in ORCL. Create
link L to ORCL without password. Selecting from a table in ORCL @L (i.e. select
* from [EMAIL PROTECTED]) throws ORA-1017 invalid username/password.
Alternatively, I logon as SYS and create a procedure owned by SYSTEM, with one
line execute imediate('select count(*) from [EMAIL PROTECTED]'). When I execute
system.this procedure as SYS, I get ORA-1005 null password given. (I could
use DBMS_SYS_SQL but using the execute immediate trick obviates the need to
remember the syntax in that undocumented package).
If I use connect to current_user to create the link, I always get ORA-28030
Server encountered problems accessing LDAP directory service.
Could you try on your databases and show how you do it? As I said, this may be
a security problem. I'm just too ignorant of it and can't reproduce it for now.
Yong Huang
Norris, Gregory T [ITS] wrote:
There's no reason I can see that he couldn't create the dblink first, and then
reset the password using the encrypted value. Alternately, the dblink could be
created using the DBMS_SYS_SQL package... no knowledge of the current password
required.
create database link foo
connect to current_user
using 'bar';
__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Yong Huang
INET: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (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).
Re: Risk of knowing password hash value (Was: OEM permissions)
Jared,
I see you log out and log back in as SYSTEM to DB2. But how do you know the
password for SYSTEM to log back in with after you change it?
What if you don't log out? When I tried that (i.e. not logging out), I got
ORA-1017.
Yong Huang
--- Jared Still [EMAIL PROTECTED] wrote:
Environment:
DB1: RH 8.0 with Oracle EE 9.2.0.4
DB2: Win2k SP3 with Oracle EE 9.2.0.1
SYSTEM user on each database initially have different passwords.
It goes something like this:
DB1:
select password from dba_users where username = 'SYSTEM';
Let's say the result is 'AC424SDK4398'
DB2:
Logon to DB2 as SYSTEM.
alter user SYSTEM identified by values 'AC424SDK4398';
create database link systemlink using 'DB1';
Logout, and log back on to DB2 as SYSTEM.
select count(*) from [EMAIL PROTECTED];
Works for me in this environment. DB2 is compromised.
HTH
Jared
On Mon, 2003-12-22 at 08:29, Yong Huang wrote:
Hi, Gregory,
I only have access to Oracle 9.2 on my laptop. Here's my test. I have ORCL
and
AUX1 databases, the latter created by RMAN DUPLICATE some time ago. I logon
AUX1 as SYSTEM. Set SYSTEM password hash value to the same as in ORCL.
Create
link L to ORCL without password. Selecting from a table in ORCL @L (i.e.
select
* from [EMAIL PROTECTED]) throws ORA-1017 invalid username/password.
Alternatively, I logon as SYS and create a procedure owned by SYSTEM, with
one
line execute imediate('select count(*) from [EMAIL PROTECTED]'). When I execute
system.this procedure as SYS, I get ORA-1005 null password given. (I
could
use DBMS_SYS_SQL but using the execute immediate trick obviates the need to
remember the syntax in that undocumented package).
If I use connect to current_user to create the link, I always get ORA-28030
Server encountered problems accessing LDAP directory service.
Could you try on your databases and show how you do it? As I said, this may
be
a security problem. I'm just too ignorant of it and can't reproduce it for
now.
Yong Huang
Norris, Gregory T [ITS] wrote:
There's no reason I can see that he couldn't create the dblink first, and
then
reset the password using the encrypted value. Alternately, the dblink
could be
created using the DBMS_SYS_SQL package... no knowledge of the current
password
required.
create database link foo
connect to current_user
using 'bar';
__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Yong Huang
INET: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (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).
Re: Risk of knowing password hash value (Was: OEM permissions)
Hi, Okay. I'm almost a believer of this as a problem. How about 9.2.0.4 on RH9.3. 1) What does anyone/everyone get for my this query (my results shown): connect system/[EMAIL PROTECTED]; alter user scott identified by tiger; -- select password from dba_users where username = 'SCOTT'; PASSWORD F894844C34402B67 2) If you all get the same, then I'm concerned. Regards, Mike Thomas --- Yong Huang [EMAIL PROTECTED] wrote: Jared, I see you log out and log back in as SYSTEM to DB2. But how do you know the password for SYSTEM to log back in with after you change it? What if you don't log out? When I tried that (i.e. not logging out), I got ORA-1017. Yong Huang --- Jared Still [EMAIL PROTECTED] wrote: Environment: DB1: RH 8.0 with Oracle EE 9.2.0.4 DB2: Win2k SP3 with Oracle EE 9.2.0.1 SYSTEM user on each database initially have different passwords. __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Michael Thomas INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
Re: Risk of knowing password hash value (Was: OEM permissions)
It doesn't matter which account I logged into DB2 with, as
long as that account has privileges to read DBA_USERS.
SYSTEM was used simply because it was the only account
on the database that could be logged into remotely, so
my test could be run without switching between machines.
If I had granted SELECT_CATALOG_ROLE to scott, I could
have logged in as SCOTT and done the same.
Jared
PS. Forgot this in private post to Yong: The password is
cached, I assume in the PGA. This doesn't work without
reconnecting. Logging out isn't strictly necessary, but
the way my shell is setup, it takes quite a few less keystrokes
to logout/logon than the type 'connect system/[EMAIL PROTECTED]'.
On Mon, 2003-12-22 at 20:19, Yong Huang wrote:
Jared,
I see you log out and log back in as SYSTEM to DB2. But how do you know the
password for SYSTEM to log back in with after you change it?
What if you don't log out? When I tried that (i.e. not logging out), I got
ORA-1017.
Yong Huang
--- Jared Still [EMAIL PROTECTED] wrote:
Environment:
DB1: RH 8.0 with Oracle EE 9.2.0.4
DB2: Win2k SP3 with Oracle EE 9.2.0.1
SYSTEM user on each database initially have different passwords.
It goes something like this:
DB1:
select password from dba_users where username = 'SYSTEM';
Let's say the result is 'AC424SDK4398'
DB2:
Logon to DB2 as SYSTEM.
alter user SYSTEM identified by values 'AC424SDK4398';
create database link systemlink using 'DB1';
Logout, and log back on to DB2 as SYSTEM.
select count(*) from [EMAIL PROTECTED];
Works for me in this environment. DB2 is compromised.
HTH
Jared
On Mon, 2003-12-22 at 08:29, Yong Huang wrote:
Hi, Gregory,
I only have access to Oracle 9.2 on my laptop. Here's my test. I have ORCL
and
AUX1 databases, the latter created by RMAN DUPLICATE some time ago. I logon
AUX1 as SYSTEM. Set SYSTEM password hash value to the same as in ORCL.
Create
link L to ORCL without password. Selecting from a table in ORCL @L (i.e.
select
* from [EMAIL PROTECTED]) throws ORA-1017 invalid username/password.
Alternatively, I logon as SYS and create a procedure owned by SYSTEM, with
one
line execute imediate('select count(*) from [EMAIL PROTECTED]'). When I execute
system.this procedure as SYS, I get ORA-1005 null password given. (I
could
use DBMS_SYS_SQL but using the execute immediate trick obviates the need to
remember the syntax in that undocumented package).
If I use connect to current_user to create the link, I always get ORA-28030
Server encountered problems accessing LDAP directory service.
Could you try on your databases and show how you do it? As I said, this may
be
a security problem. I'm just too ignorant of it and can't reproduce it for
now.
Yong Huang
Norris, Gregory T [ITS] wrote:
There's no reason I can see that he couldn't create the dblink first, and
then
reset the password using the encrypted value. Alternately, the dblink
could be
created using the DBMS_SYS_SQL package... no knowledge of the current
password
required.
create database link foo
connect to current_user
using 'bar';
__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Yong Huang
INET: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (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).
Re: Risk of knowing password hash value (Was: OEM permissions)
On RH 8.0 Oracle 9.2.0.4: F894844C34402B67 It is required that a password for a particular users always hashes to the same value, regardless of platform or Oracle version. This has been true for as long as I have used oracle: since 7.0.13. If not, export/import would not be able to recreate users, and database links without a password would not work. Good reason to protect DBA_USERS, no? Jared On Mon, 2003-12-22 at 20:44, Michael Thomas wrote: Hi, Okay. I'm almost a believer of this as a problem. How about 9.2.0.4 on RH9.3. 1) What does anyone/everyone get for my this query (my results shown): connect system/[EMAIL PROTECTED]; alter user scott identified by tiger; -- select password from dba_users where username = 'SCOTT'; PASSWORD F894844C34402B67 2) If you all get the same, then I'm concerned. Regards, Mike Thomas --- Yong Huang [EMAIL PROTECTED] wrote: Jared, I see you log out and log back in as SYSTEM to DB2. But how do you know the password for SYSTEM to log back in with after you change it? What if you don't log out? When I tried that (i.e. not logging out), I got ORA-1017. Yong Huang --- Jared Still [EMAIL PROTECTED] wrote: Environment: DB1: RH 8.0 with Oracle EE 9.2.0.4 DB2: Win2k SP3 with Oracle EE 9.2.0.1 SYSTEM user on each database initially have different passwords. __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Michael Thomas INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
Re: Risk of knowing password hash value (Was: OEM permissions)
Yes, I misunderstood.
Once I change the password, I can no longer connect to the account.
My hasty little test was missing an important condition: I should
have pretended I didn't know the password to the other database,
which would prevent me from logging back on exploiting the db link.
Wonder if there's a way around it though?
I spent a few minutes looking for a way around that problem, and
couldn't find one. Oracle may have covered the bases on this, they've
had a few years to perfect it.
Jared
On Mon, 2003-12-22 at 21:19, Yong Huang wrote:
Hey, you're working late!
OK. I think you misunderstood. I know you take SYSTEM as an example user. Let's
say it's SCOTT who has select_catalog_role. If you login to your own database
as SCOTT and change his password hash value, you don't know the clear text
password any more. How can you log out and log back in as SCOTT? That's why I
ask if you can use the link without logging out after changing the password?
Yong
--- Jared Still [EMAIL PROTECTED] wrote:
It doesn't matter which account I logged into DB2 with, as
long as that account has privileges to read DBA_USERS.
SYSTEM was used simply because it was the only account
on the database that could be logged into remotely, so
my test could be run without switching between machines.
If I had granted SELECT_CATALOG_ROLE to scott, I could
have logged in as SCOTT and done the same.
Jared
On Mon, 2003-12-22 at 20:19, Yong Huang wrote:
Jared,
I see you log out and log back in as SYSTEM to DB2. But how do you know the
password for SYSTEM to log back in with after you change it?
What if you don't log out? When I tried that (i.e. not logging out), I got
ORA-1017.
Yong Huang
--- Jared Still [EMAIL PROTECTED] wrote:
Environment:
DB1: RH 8.0 with Oracle EE 9.2.0.4
DB2: Win2k SP3 with Oracle EE 9.2.0.1
SYSTEM user on each database initially have different passwords.
It goes something like this:
DB1:
select password from dba_users where username = 'SYSTEM';
Let's say the result is 'AC424SDK4398'
DB2:
Logon to DB2 as SYSTEM.
alter user SYSTEM identified by values 'AC424SDK4398';
create database link systemlink using 'DB1';
Logout, and log back on to DB2 as SYSTEM.
select count(*) from [EMAIL PROTECTED];
Works for me in this environment. DB2 is compromised.
HTH
Jared
On Mon, 2003-12-22 at 08:29, Yong Huang wrote:
Hi, Gregory,
I only have access to Oracle 9.2 on my laptop. Here's my test. I have
ORCL
and
AUX1 databases, the latter created by RMAN DUPLICATE some time ago. I
logon
AUX1 as SYSTEM. Set SYSTEM password hash value to the same as in ORCL.
Create
link L to ORCL without password. Selecting from a table in ORCL @L
(i.e.
select
* from [EMAIL PROTECTED]) throws ORA-1017 invalid username/password.
Alternatively, I logon as SYS and create a procedure owned by SYSTEM,
with
one
line execute imediate('select count(*) from [EMAIL PROTECTED]'). When I
execute
system.this procedure as SYS, I get ORA-1005 null password given. (I
could
use DBMS_SYS_SQL but using the execute immediate trick obviates the
need to
remember the syntax in that undocumented package).
If I use connect to current_user to create the link, I always get
ORA-28030
Server encountered problems accessing LDAP directory service.
Could you try on your databases and show how you do it? As I said, this
may
be
a security problem. I'm just too ignorant of it and can't reproduce it
for
now.
Yong Huang
Norris, Gregory T [ITS] wrote:
There's no reason I can see that he couldn't create the dblink first,
and
then
reset the password using the encrypted value. Alternately, the dblink
could be
created using the DBMS_SYS_SQL package... no knowledge of the current
password
required.
create database link foo
connect to current_user
using 'bar';
__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Jared Still
INET: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the
Re: Risk of knowing password hash value (Was: OEM permissions)
8.1.7 on win2000 SQL select password 2 from dba_users 3 where username = 'SCOTT'; PASSWORD -- F894844C34402B67 - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Tuesday, December 23, 2003 11:44 AM Hi, Okay. I'm almost a believer of this as a problem. How about 9.2.0.4 on RH9.3. 1) What does anyone/everyone get for my this query (my results shown): connect system/[EMAIL PROTECTED]; alter user scott identified by tiger; -- select password from dba_users where username = 'SCOTT'; PASSWORD F894844C34402B67 2) If you all get the same, then I'm concerned. Regards, Mike Thomas --- Yong Huang [EMAIL PROTECTED] wrote: Jared, I see you log out and log back in as SYSTEM to DB2. But how do you know the password for SYSTEM to log back in with after you change it? What if you don't log out? When I tried that (i.e. not logging out), I got ORA-1017. Yong Huang --- Jared Still [EMAIL PROTECTED] wrote: Environment: DB1: RH 8.0 with Oracle EE 9.2.0.4 DB2: Win2k SP3 with Oracle EE 9.2.0.1 SYSTEM user on each database initially have different passwords. __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Michael Thomas INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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: rahul sharma INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
