Oracle password encryption algorithm?
Dave Trahan
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
>
> 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
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
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
>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
> 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)
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
>>
>> 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
|> 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
Carl Brewer
>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.
this is possible. If your passwd choice is poor, and/or the crypt routine
is weak. Any decent passwd crypt will be a one-way algorythm, the only
way to break it is by brute force.
>
> 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.
Not quite true. Most security concious sites have implimented shaddow
passwording, but it's true, if you use the UNIX crypt() algorythm, and your
passwd is a "good" passwd, then to crack by brute force takes several hundred
years using a network of 20 Sun SPARC 2's.
>
> 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.
passwds should *NEVER* be plaintext stored anywhere(on a multi-user OS anyway,
dos stuff doesn't matter, its security is a joke anyway). Any programme that
takes passwords seriously should not use an argv for password entry. C has
a system call to do it for you ( getpass() ) and it's fairly trivial to write
one yourself. Of course, if the passwding in Oracle was designed as a gimick,
rather than serious security .....
--
Carl Brewer Ph :61-9-380-1893 | #include \
Systems/Network Officer, Reid Library Fax:61-9-380-1012 | <std_disclaimer.h>
University of Western Australia ca...@oversteer.library.uwa.edu.au
Merlin, where are you? Call your Dragon, to weave a mist ....
Christian A. Ratliff
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.
Paul Mickel
>
> 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. :)
It is in plaintext if it is entered on the command line. I realize the danger
of doing this, but since this is the case, MHO is that the Oracle products
should not even ALLOW the option of entering the passwd on the command line
for security reasons.....
Dan Wing
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
: 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
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.