- Oracle Secutriy
- Strong Password Hash Algorithm
- Out of Box Security features
- Delayed Failed Logins
- Case Sensitive passwords
Oracle Security features is by no means a second thought in today’s database system design. It is a part of the overall design strategy and can be a major concern when choosing one database over another. The most important aspect of security is the ability to protect the systems from outside access. The other aspect is to keep in check access to the data by internal use by employees. Acts like SOX are a result of employees infringing their own organization’s data rules and stealing important information. So with this it is very important that whatever database management system you are using it provides the ability to protect your data in both scenarios.
Oracle is well aware of this and it therefore continues to introduce newer features to enhance the Oracle security, with every release of database. Oracle 11g is heavily equipped with user security related features. Here is a look at some of these.
Strong Password Hash Algorithm
In 11g Oracle Security introduces the use of a new hashing algorithm SHA-1 for password protection. It is much more stronger than any other hashing algorithm used previously and the it’s name portrays it strength – Strong Hashing Algorithm (SHA). By employing this, Oracle Security is enforcing a strong compliance requirement required for users connecting to the database.
Apart from hashing the password, Oracle also applies a SALT to this function. The SALT is randomly generated and is appended to the end of the every password hash. This further helps prevent hackers from using matching patterns to guess an individual’s password.
Out of Box Security features
Starting with 11g, Oracle has also introduced new security settings for every database which has been created using the DBCA utility. However during the database creation phase, you have the option of choosing these new settings or to opt out from them. These security settings are SOX compliant and meet the requirement of implementing proper security settings for internal users.
There are two major parts of these new settings, which are:
In addition to this, the default value of AUDIT_TRAIL parameter is set to DB in 11g. You can set this parameter to the value EXTENDED_DB if your application has a requirement to audit the SQL and bind variables. Once you have turned the auditing on, you can query the following table to list the privileges which are being audited.
SQL> select privilege, success, failureThe performance overhead of these new settings is very minimal.
order by privilege;
All the privileges which are returned by the above query will be audited every time they are used. Logging in and logging out of the database users is also recorded.
The AUD$ table which is used to record all this auditing related information must be moved out of the SYSTEM tablespace. Also it is very important that you audit the DML on the AUD$ table. This will alert you if there is any unauthorized tampering of the data in AUD$ table itself.
Apart from the auditing enhancements, the other area where these new security settings have been enhanced, is the password profile. The default password profile enforces strict values compliant with the SOX requirement. The values for the new profile settings are as follows.
The first three options i.e. PASSWORD_LOCK_TIME, PASSWORD_GRACE_TIME and PASSWORD_LIFE_TIME have a more stricter values than in 10gR2 and before.
Delayed Failed Logins
If a user is trying to log into the database using a wrong password then he or she will get a delayed response after the first three failed attempts. This is enabled by default in 11g. In this way, Oracle preserves the performance of the database by delaying the response to users who may be violating security. Even if the user changes the host to attempt to connect to the database or tries from a different IP, he or she will still have the same delayed response.
In testing we have seen that this delay can be up to ten seconds. It has been observed that the first attempt with wrong password was responded back in less then a second but by the eighth iteration the response back was delayed by up to seven seconds.
Case Sensitive passwords
Previously the Oracle user passwords were not case sensitive. For added security this long tradition has been changed to enhance Oracle Security. Now you can enforce case sensitive passwords for Oracle database users. If the default security settings is employed then case sensitivity is enabled by default. However if you have not opted for case default security settings but now want passwords to be case sensitive then you need to set the SEC_CASE_SENTITIVE_LOGON parameter value to true, using the following command.
SQL> alter system set sec_case_sensitive_logon = TRUE;
From this point on all the new passwords will be case sensitive. If you set the password for Scott user to Tiger and attempt to log in using tiger (as an old habit) then you will returned an incorrect username/password error message.
Another interesting topic on using DBMS_ASSERT to protect against SQL injection.