Distributed database security

A methodology for accrediting a commercial distributed database

“…Table 2 shows the degree to which Oracle 7.2 implements this criteria. Oracle 7.2 does not have the ability to ensure a trusted path between client and server, or between server and server (Harris, et al, 1994). This means that there is no way in which the client could be certain that he/she is responding to the trusted server when passing user IDs and passwords in an attempt to log onto the database.…”

“…This protocol makes use of a different encryption key for each session. Every session the client opens with the server will, therefore, have the same password encrypted to different values (Harris, et al, 1994), making it very difficult for an eavesdropper to try and decrypt the encrypted password.…”

“…Oracle 7.2 provides the facility of twofold identification: either the identification can be left up to the operating system or every user requesting a session with the database will have to provide a usemame and password. In case the identification and authentication process is left up to the operating system, users' IDs and passwords will be validated by the operating system mechanisms, and database roles may be mapped to operating system groups (Harris, et al, 1994). The user will, therefore, receive the database privileges associated with the operating system group for which it was authenticated.…”

“…There are, however, some deficiencies in the current password mechanisms Oracle 7.2 is using. Oracle does not manage a minimum password length and suitable time periods requiring password changes (Harris, et al, 1994). This may, however, be overcome by educating staff members to keep their passwords secret, to choose them carefully and to change them regularly.…”