15868

神经网络昆斯林的新闻组分类2006

Xref: cantaloupe.srv.cs.cmu.edu comp.databases.oracle:4258 comp.security.misc:3550 sci.crypt:15868
Newsgroups: comp.databases.oracle,comp.security.misc,sci.crypt
Path: cantaloupe.srv.cs.cmu.edu!rochester!udel!darwin.sura.net!gatech!howland.reston.ans.net!usc!sol.ctr.columbia.edu!eff!world!fw
From: [e-mail] (forrest d whitcher)
Subject: SUMMARY: responses / research on oracle password security
Message-ID: <[e-mail]>
Summary: oracle password encryption, security
Keywords: oracle rdbms os/2 unix network password DES
Organization: The World Public Access UNIX, Brookline, MA
Date: Fri, 23 Apr 1993 21:09:53 GMT
Lines: 68

My original post was:

>I am building an oracle v6 database to serve as a repository for
>information which is considered proprietary or confidential. As such
>I want to verify the security of oracle passwords and apply some of
>the same security checking techniques we use on our *nix systems.
>Specifically I would like to use Crack, or something like it to check
>the encrypted data for easily guessed passwords.
>
>The use of 'Crack' would depend on oracle using the unix password
>encryption scheme, does anyone know if this is the case, or what
>method is used?
>
>Any other methods for security checking / audit in the oracle
>environment would be much appreciated.

This article will just scratch the surface of a few security
considerations, comments are requested. (email: [e-mail])
My thanks to the people who responded, both on usenet and from
Oracle Corp.

The most common response was to suggest use of oracle audit 
features or OPS$ passwords to control access (opinion on OPS$
included suggestions to use and not use). I was also advised to 
use table views to refine the granularity of access control.

One important security consideration in networked installations
is that OPS$ accounts presume that the client host provides user
authentication. Os/2 server OPS$ users are only as secure as the 
_least_ secure machine on the network. Hence you should probably 
not define any OPS$ accounts on systems with PC's, or limit access 
of OPS$ accounts to data with no security concerns. Unix oracle 
servers provide for disabling OPS$ access over the network (orasrv
option), while relying on host security for local processes. 

Internally Oracle provides powerful and well documented (sic) 
audit mechanisms which the DBA will use to monitor system and
data access. These tools can be used to track the primary security
risks from within the Oracle environment.

Oracle password security is based on a proprietary usage of DES
encryption. Oracle Corp. states that the algorithm is not prone
to cleartext attack. This is a difficult claim to substantiate 
since the algorithm is unknown. The concern here is that if users 
choose easily guessed passwords. _If_ a cracker can gain access 
to your oracle database files through the host operating system, 
s/he could extract the 'cyphertext' password data and apply 
cryptanalysis techniques to learn the users passwords.

As security risks go, the above scenario is pretty low severity.
Certainly once an intruder has access to the raw database files,
s/he can access to the data in them. If a cracker _could_ break 
the passwords, however, s/he could do substantial damage without
alerting the auditing mechanism's, and leaving and audit trail
which would point to valid users. At present Oracle (like Unix)
provides no native means of ensuring that passwords are not 
guessable. 

As with all computer security, the most important defense is to 
educate users in the safe choice of passwords. These techniques
are well discussed in internet rfc#1281 and the Crack manual, 
(both available from ftp archive servers) and, UNIX(R) System 
Security (Curry, David A. - Addison-Welsey 1992) 



Forrest Whitcher                 [e-mail]
Boston Scientific Corp.          Watertown MA