SUMMARY: responses / research on oracle password security

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: fw_at_world.std.com) 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                 fw_at_world.std.com
Boston Scientific Corp.          Watertown MA