Hi
There are risks with knowing the password hash for any user not just
system. Unfortunately reading it from dba_users is not the only way to
get it. There are a number of other options as well that i won't go into
here.
As Arup pointed out the password hash is calculated from the username
and
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
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
[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
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
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
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
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
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.
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
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
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
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
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
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
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:
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:
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
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
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
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
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.
Hi,
I think you're describing a real security hole. But I'm not sure how it's
exploited exactly. Let's say John Doe sets up his database on his desktop,
which is part of the production database network. He sees the hash value of
SYSTEM's password on production and sets the hash value for his own
You could use protocol.ora to specify which machines are
allowed to make a connection to the database.
In some environments this would be fairly painless.
SAP for example. The users do not connect to the database,
they connect to the app server. The number of machines
that legitimately require
I believe the point is not that you can create links to SYS or
SYSTEM accounts, but instead to application accounts, e.g. if I
created a link from my private database to the company's HR
database using a duplicated HR_MANAGER schema, I may be able to
access data that I otherwise should not
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
-L [EMAIL PROTECTED]
cc:
Subject:RE: OEM permissions
Raj - Thanks for your reply. Were this a consultant, my reply would mirror
yours, and maybe not so diplomatically.
But basically I manage these databases on behalf of this manager, so
when
he asks for read-only
Hi, Raj,
9i doesn't allow a user with select any table privilege to view any object
owned by SYS. So the sys.link$ risk is gone. But select any dictionary, a new
privilege in 9i, allows that. In practice, I always grant select_catalog_role
to any developer, but refrain from granting select any
A possibly related question:
I'm curious if everyone allows your developers to see
V$SQL... views? If not, then ... whatever ... no
comment.
I'm disappointed with some perspectives in these
threads regarding developers. Rather than close doors,
why not use 'development' instances, and role based
recipients of list ORACLE-L
Subject: RE: OEM permissions
A possibly related question:
I'm curious if everyone allows your developers to see
V$SQL... views? If not, then ... whatever ... no
comment.
I'm disappointed with some perspectives in these
threads regarding developers. Rather
Sure it does, just not by default. Check out the
07_DICTIONARY_ACCESSIBILITY parameter.
Enjoy!
Rich
Rich Jesse System/Database Administrator
[EMAIL PROTECTED] Quad/Tech Inc, Sussex, WI USA
-Original Message-
Sent: Friday, December 19, 2003
That's why we have scripts which give us a report every few days on users that have
db_links, any of the *_ANY_* privs (like alter any table), dba privs etc, also a list
of some sensitive schemas too.
Our application support needed to work with users to grant/revoke roles and private
synonyms.
We have a new manager that wants his group to use OEM for development
access, as an alternative to Toad. He has requested a special Oracle userid
with the following grants:
SELECT_CATALOG_ROLE
SELECT ANY DICTIONARY
SELECT ANY TABLE
Does this seem reasonable for OEM? The manager is
Dennis,
select any table has to be a big no no ... anyone can select from sys.link$. But I
am still trying how OEM can be used for _development_?? what am I missing? As for
One of our groups hired a new consultant and he (claimed to have DBA background)
immediately shot off an email saying he
Wouldn't this allow viewing DBA_USERS?
I haven't tried this myself, but it seems that I could set up another oracle
instance, create a user identified by values, then create database link.
-Original Message-
We have a new manager that wants his group to use OEM for development
Raj - Thanks for your reply. Were this a consultant, my reply would mirror
yours, and maybe not so diplomatically.
But basically I manage these databases on behalf of this manager, so when
he asks for read-only access, I can't really refuse. And I think he is
pretty competent as a DBA. He says
Dennis,
I think you are probably ok with this. But the best way to do this is to
create an Oracle account, grant what he asks, and start OEM using that
account. Try and change things and see what happens. Then you will know
for sure what the impact is.
Good Luck!
Tom Mercadante
Oracle
I would say OEM for dbas only. To difficult to manage for developers.
Dangerous. Too much low level stuff for managers and developers to poke
around with.
OEM is not really a development tool.
2 cents
-Original Message-
Sent: Thursday, December 18, 2003 8:24 AM
To: Multiple
Raj, Thomas, Brad, Bill, anyone I forgot - I feel better about the situation
now. Thanks for letting me run this issue past you.
Dennis Williams
DBA
Lifetouch, Inc.
[EMAIL PROTECTED]
-Original Message-
Sent: Thursday, December 18, 2003 9:35 AM
To: Multiple recipients of list ORACLE-L
39 matches
Mail list logo
