Oracle password encryption algorithm?

467 views
Skip to first unread message

Dave Trahan

unread,
Jun 30, 1993, 11:43:24 AM6/30/93
to

Does anyone know what algorithm Oracle uses to encrypt user passwords? Has
it changed in the last several versions (5,6,7)? Is there a "public" way
to access this routine? Is the algorithm the same on all platforms?

I'm trying to write a tool to find users who have set their Oracle password
to be the same as their Oracle username. I'm familiar with the method used
in such system tools as COPS, and I'm trying to apply the same technique
to Oracle, but without the encryption algorithm, I'm kinda stuck. I heard
it was based on the Unix 'crypt' algorithm, but with a minor change.


Any thoughts?


Dave Trahan
DETR...@TASC.COm

pih...@cbr.hhcs.gov.au

unread,
Jun 30, 1993, 11:40:33 PM6/30/93
to
In article <1993Jun30.154324.1@cissys>, tra...@cissys.read.tasc.com (Dave Trahan) writes:
>
> Does anyone know what algorithm Oracle uses to encrypt user passwords?

Hopefully, only Oracle and it's well guarded. If everyone knew the algorithm
then there would be no point in having a password because the encrypted value
is stored (visible) in the database and you could run a program to crack
anyone's account.

> Has it changed in the last several versions (5,6,7)?

Yes. From V5 to V6 they went to fixed length encryption values (at least).

> Is there a "public" way to access this routine?

If there was then it wouldn't be a secure database.

>Is the algorithm the same on all platforms?

It doesn't need to be but I assume it is.

>
> I'm trying to write a tool to find users who have set their Oracle password
> to be the same as their Oracle username. I'm familiar with the method used
> in such system tools as COPS, and I'm trying to apply the same technique
> to Oracle, but without the encryption algorithm, I'm kinda stuck. I heard
> it was based on the Unix 'crypt' algorithm, but with a minor change.
>
>
> Any thoughts?

Yes. Write a tool that tries to logon with a password equal to the username
for EACH Oracle account you have. If it succeeds in logging in then you can
tell them to get their act together otherwise you can assume it's
reasonably safe. You could keep a checklist of passwords to try : like
first name, last name, middle name, Oracle Userid, Operating System
Userid, etc etc etc.


Bruce... pih...@cbr.hhcs.gov.au

Ruth Larson

unread,
Jul 1, 1993, 9:22:15 AM7/1/93
to

Here's a "quick and dirty" way to do what you want in Version 6. Version 5
would be similar and I assume V7 also.

set pages 0
set heading off
column username format a12
spool temp_sql
select 'connect ',username,'/',username,' ',
'select user from dual;'
from system.dba_users;
spool off
@temp

You'll get a couple of error messages for each pw that isn't the username
but every so often:

CONNECTED
username

In other words, a "Bingo".

(I *did* say "quick and *dirty*") :-)

Ian A. MacGregor

unread,
Jul 1, 1993, 12:42:28 PM7/1/93
to
In article <1993Jun30.154324.1@cissys>, tra...@cissys.read.tasc.com (Dave Trahan) writes:
|>


The oracle password encyption algorithm always encrypts the plain text password
string to the same encrypted string provided that the usernames are the same.
Thus if you wrote

grant connect to scott identified by scott;

and then

select password from sys.dba_users
where username = 'SCOTT';

each time you ran the two statements, the encrypted password displayed by the
second would be the same. However, if you were to write

grant connect to king identified by scott;

and then
select password from sys.dba_users
where username = 'KING';

the encrypted password would be different from the first example.

In order to test whether scott's password is scott you can do the following:

select password from sys.dba_users
where username = 'SCOTT';

carefully copy the encrypted password. Next issue

grant connect to scott identified by scott;

rerun

select password from sys.dba_users
where username = 'SCOTT';

compare the two encrypted passwords. If they are the same then the original
password for user scott was scott.

If not you'll need to restore the user's original password. You can do this with
the following statement

grant connect to scott
identified by values '<original_encrypted_password_string>';

Ian MacGregor
Stanford Linear Accelerator Center
(415) 926-3528



Lee Parsons

unread,
Jul 2, 1993, 5:33:13 PM7/2/93
to
In article <1993Jul1...@cbr.hhcs.gov.au> pih...@cbr.hhcs.gov.au writes:
>In article <1993Jun30.154324.1@cissys>, tra...@cissys.read.tasc.com (Dave Trahan) writes:
>>
>> Does anyone know what algorithm Oracle uses to encrypt user passwords?
>
>Hopefully, only Oracle and it's well guarded. If everyone knew the algorithm
>then there would be no point in having a password because the encrypted value
>is stored (visible) in the database and you could run a program to crack
>anyone's account.
>

The unix encryption algorithm is well known but considered secure against
brute force attackes. If the security of my database depends on the good
will of the couple of 1000 oracle employees that know the algoithm, then
I don't want it. The scheme has to still be workable when the algorithm
becomes well know because sooner or later it will.

The answer is good passwords that a password cracker won't guess.
ie) upper case + lower case + special character

[...]


>>Is the algorithm the same on all platforms?
>
>It doesn't need to be but I assume it is.
>

I have moved the encripted values between unix boxes and to
a Vax system with no problem.
--
Regards,

Lee E. Parsons Baker-Huges Inteq, Inc
Oracle Database Administrator lpar...@exlog.com

g...@hadassah.bitnet

unread,
Jul 5, 1993, 7:53:13 AM7/5/93
to
In article <1993Jul2.2...@exlog.com>, lpar...@exlog.com (Lee Parsons) writes:
> In article <1993Jul1...@cbr.hhcs.gov.au> pih...@cbr.hhcs.gov.au writes:
>>In article <1993Jun30.154324.1@cissys>, tra...@cissys.read.tasc.com (Dave Trahan) writes:
>>>
>>> Does anyone know what algorithm Oracle uses to encrypt user passwords?
>>
>>Hopefully, only Oracle and it's well guarded. If everyone knew the algorithm
>>then there would be no point in having a password because the encrypted value
>>is stored (visible) in the database and you could run a program to crack
>>anyone's account.
>

[. . .]

Just compare the situation with the VMS passwords.
Not only the algorithm is known, but there is even a system service to
encrypt a string using it. However the users authorization file is
inaccessible to unprivileged mortals.


PIOCH Nicolas (Nap)

unread,
Jul 5, 1993, 10:08:54 AM7/5/93
to
In his delirium, g...@hadassah.bitnet
babbled the following on comp.databases.oracle,comp.security.misc:
X In article <1993Jul2.2...@exlog.com>, lpar...@exlog.com (Lee Parsons) writes:
X > In article <1993Jul1...@cbr.hhcs.gov.au> pih...@cbr.hhcs.gov.au writes:
X >>then there would be no point in having a password because the encrypted value
X >>is stored (visible) in the database and you could run a program to crack
X Just compare the situation with the VMS passwords.
X Not only the algorithm is known, but there is even a system service to
X encrypt a string using it. However the users authorization file is
X inaccessible to unprivileged mortals.

Just compare the situation with the Uni*x passwords.
Not only is the algorithm known, but there is even a system service to
encrypt a string using it, and packages to crack /etc/passwd's files,
and users gaining rewt access because r00t has a suid-bit shell-script
to clean /tmp or reset the printer or whatever.

Paul Mickel

unread,
Jul 5, 1993, 10:57:16 PM7/5/93
to
>In article <1993Jun30.154324.1@cissys>, tra...@cissys.read.tasc.com (Dave Trahan) writes:
>>
>> Does anyone know what algorithm Oracle uses to encrypt user passwords?
>
>Hopefully, only Oracle and it's well guarded. If everyone knew the algorithm
>then there would be no point in having a password because the encrypted value
>is stored (visible) in the database and you could run a program to crack
>anyone's account.

However, it makes no sense to encrypt the passwd if you can see it from the
process table on the box running the application. I discovered this
just the other day when I was killing some processes that were running
sqlforms30. Doing a 'ps -fu extract' I found the following:

78977 78971 0:20 p2 sqlforms30 -c extract:vt220 extract/<mypasswd>

(process numbers were different and the columns of table may be off a little,
but did contain all this information.)

While I didn't test this with other Oracle products that we had, the fact this
occurred at all makes me wonder how extensive this problem is. By implication,
I could gain the DBA's passwd while they are on and have LOTS of fun.....

This is under Oracle version 6.0.36

[some deleted]

>> I'm trying to write a tool to find users who have set their Oracle password
>> to be the same as their Oracle username. I'm familiar with the method used
>> in such system tools as COPS, and I'm trying to apply the same technique
>> to Oracle, but without the encryption algorithm, I'm kinda stuck. I heard
>> it was based on the Unix 'crypt' algorithm, but with a minor change.
>>
>>
>> Any thoughts?
>
>Yes. Write a tool that tries to logon with a password equal to the username
>for EACH Oracle account you have. If it succeeds in logging in then you can
>tell them to get their act together otherwise you can assume it's
>reasonably safe. You could keep a checklist of passwords to try : like
>first name, last name, middle name, Oracle Userid, Operating System
>Userid, etc etc etc.

Yeah, if you are concerned at all about security of your database, DON'T do
this. This makes your database system just as unsecure as the Unix box if you
were to allow the same thing on it........

-Paul

--
Paul M. Mickel Internet:mic...@oes.orst.edu
Database Programmer, Teledyne Wah Chang Albany, OR 97321
Disclaimer: My employer never claims my opinions (unless it makes a profit).

Trammell B. Hudson

unread,
Jul 5, 1993, 11:09:16 PM7/5/93
to
In article <21apmc$1...@gaia.ucs.orst.edu>, mic...@OES.ORST.EDU (Paul Mickel) writes:
|> In article <1993Jul1...@cbr.hhcs.gov.au> pih...@cbr.hhcs.gov.au writes:
|> >In article <1993Jun30.154324.1@cissys>, tra...@cissys.read.tasc.com (Dave Trahan) writes:
|> >>
|> >> Does anyone know what algorithm Oracle uses to encrypt user passwords?
|> >
|> >Hopefully, only Oracle and it's well guarded. If everyone knew the algorithm
|> >then there would be no point in having a password because the encrypted value
|> >is stored (visible) in the database and you could run a program to crack
|> >anyone's account.

Wait! Why do encryption algorythms have to be guarded? Didn't UNIX
leave the /etc/passwd file with encrypted passwds in plain view for years?
If the algorythm is sufficiently nonreversible, then the algorythm AND the
encrypted passwds can be in plain view with out any problems.

Having the passwd in the argv for a program is another matter. That
is serious is plaintext passwds are stored for any longer than necessary.


Direct all comments to this newsgroup or:
tbhu...@whale.st.usm.eduu lshu...@nsula.edu tramm_...@agwbbs.us
tr...@bourbon.ee.tulane.edu tr...@lsmsa.nsula.edu ro...@192.102.223.10

Direct all complaints to /dev/null at the site of your choice.

The oceans are full of dirty fish, huh? See the fnords


Christian A. Ratliff

unread,
Jul 6, 1993, 8:36:28 AM7/6/93
to

Is this '<mypasswd>' in plaintext or encrypted? This concerns me as
the Oracle rep I spoke with a few weeks ago told me that their security
was impecable. Particularly since he said they did not pass any plaintext
passwords over the network. However, listing it in the process table is just
as bad. :)


In article <21apmc$1...@gaia.ucs.orst.edu>, mic...@OES.ORST.EDU (Paul Mickel) writes:

> However, it makes no sense to encrypt the passwd if you can see it from the
> process table on the box running the application. I discovered this
> just the other day when I was killing some processes that were running
> sqlforms30. Doing a 'ps -fu extract' I found the following:
>
> 78977 78971 0:20 p2 sqlforms30 -c extract:vt220 extract/<mypasswd>
>
> (process numbers were different and the columns of table may be off a little,
> but did contain all this information.)
>
> While I didn't test this with other Oracle products that we had, the fact this
> occurred at all makes me wonder how extensive this problem is. By implication,
> I could gain the DBA's passwd while they are on and have LOTS of fun.....
>
> This is under Oracle version 6.0.36

thanks,
christian

---------
Christian Ratliff Cabletron Systems, Inc.
EDGE System Developer Rochester, NH 03867
rat...@ctron.com <NeXTmail OK> Work: (603) 337-1209
"I'm a NeXTSTEP man; I'm an SGI guy." Home: (207) 780-NeXT
Nobody at Cabletron knows, approves of, or recalls my opinions.

Dan Wing

unread,
Jul 6, 1993, 7:02:12 PM7/6/93
to

The primary strength of the VMS password encryption scheme isn't that the
ciphertext is protected from non-privileged users.

The primary strength is that the passwords are encrypted with a one-way
function; once the data (the password) has been encrypted, it cannot be
decrypted into its original form without a brute-force attack. The fact that
the file containing the encrypted passwords is unavailable to non-privileged
users only prevents a non-privileged user from performing a brute-force
attack on the encrypted data.

-dan

(who knows only a little about most things, and even less about cryptography).

-Dan Wing, dw...@uh01.colorado.edu

Szymon Sokol

unread,
Jul 7, 1993, 5:09:52 AM7/7/93
to
Dan Wing (dw...@uh01.colorado.edu) wrote:
: The primary strength of the VMS password encryption scheme isn't that the

: ciphertext is protected from non-privileged users.

: The primary strength is that the passwords are encrypted with a one-way
: function; once the data (the password) has been encrypted, it cannot be
: decrypted into its original form without a brute-force attack. The fact that
: the file containing the encrypted passwords is unavailable to non-privileged
: users only prevents a non-privileged user from performing a brute-force
: attack on the encrypted data.

And the same holds for Unix. In Unix, though, the default is to have
/etc/passwd world-readable, thus brute-force attacks are possible, unless
your version of Unix has password shadowing...
--
U U M M M M Szymon Sokol -- Network Manager
U U MM MM MM MM University of Mining and Metallurgy, Computer Center
U U M M M M M M M M ave. Mickiewicza 30, 30-059 Krakow, POLAND
UUUUU M M M M M M TEL. +48 12 338100 EXT. 2885 FAX +48 12 338907

Bob Baldwin

unread,
Jul 8, 1993, 5:49:12 PM7/8/93
to
Dave Trahan wants to know the Oracle password algorithm so
he can check for weak passwords. When I was the project
lead for Trusted Oracle I designed the new password algorithm
that is used in versions 6, 7, and later. I presented the
details at a Bay Area Trusted System Symposium so I am not
revealing any information that is not already in the puiblic
domain. Here are some of the details as I remember them.

Design Goals:
1. Must work with all terminals.
===> Some terminals do not have lowercase letters, so
the password algorithm ignores differences between
upper and lower case!!! The passwords "Tiger"
and "tiger" map to the same value.

2. Must support usernames and passwords that include non-ascii
characters.
The username and password are converted to
16 bit per character representation before any processing
is done. Ascii characters have the high byte zeroed.

3. If different users have the same password, then the one-way
hash value (encrypted value) for the passwords will be different.

4. Long passwords are supported.
I believe that usernames and passwords can both be 40 chars.

Implementation:
1. Upshift password, convert to 16bits per character, and place
result left justified in an 80 byte array of zeros.

2. Using DES in cipher block feedback mode compute the CBC checksum for
the 80 byte password array using a fixed secret password (you can find
it in the code if you look hard enough). The result is used as the
key for the next step ignoring parity bits to produce the a 56 bit
key from the CBC.

3. Upshift password, and convert to 16bits per character, and place
result left justified in an 80 byte array of zeros.

4. Using DES in cipher block feedback mode compute the CBC checksum
for the 80 byte username array using the key generate in step 2.

5. Convert the CBC checksum from step 4 into a printable string with
the obvious algorithm.

--Bob Baldwin
Director of Development We provide the best solutions
Los Altos Technologies, Inc. to our customers key security
bal...@lat.com problems.

Reply all
Reply to author
Forward
0 new messages