Security, Policies and Tips - Part 7

Dear Readers,

My name is Franz Devantier, creator of this blog.  I am an Oracle Certified Professional (OCP DBA 11g) Security DBA.  I will be sharing with you the basic duties of an Oracle DBA, and also some of the undocumented, and not so well known tasks. 

Security, Policies and Tips  -  Part 7

Use Role Passwords Unknown to the User

You should grant privileges through roles that require a password.  The role password should not be known to the user.   The privileges granted to this role, should be those privileges that are needed within an application.

You enable these roles within the application by issuing a SET ROLE statement.  The password for this role is known only by the creator of the role.  The password must be embedded in the application, or retrievable from a database table, that is accessed by the stored procedure.  Preferably the password should be stored in encrypted form in the database table.

When the password for the role is hidden in such a way, it tends to discourage the average user from trying to use the privileges without using the application.  This setup will improve your overall security, but it is not foolproof, because it is essentially Security by obscurity.

Security by obscurity is not a good security practice.  This type of security will protect against lazy users who merely want to bypass the application.  Some of these users will potentially have access to the application code, and could find the passwords for the roles, if they wanted to.

Security by obscurity will not protect against malicious users.  It is possible to decompile compiled application code, into source code.  Such users could then search through the source code to find the embedded passwords, or the algorithms, that were used to encrypt the stored passwords.  Decompiled code is not as easily readable as conventional source code, but it can be used to rebuild applications if required.  

Of course even with the algorithm for the password, stored in a database table, the user will still not have execute permission on the procedure which access the table where the encrypted passwords are stored.  Also they would not have any permissions on the table where the password is stored.

However a malicious user may eventually be able to obtain the execute privileges on the stored procedure and retrieve the role password.  In such a case you security would have been compromised, but it will take some work to compromise.  However embedding the passwords, and protecting them from the average user, will go a long way to good security.

Franz Devantier,

Need a database health check, or a security audit?

devantierf@gmail.com

Income stabilizer (win-win opportunity)

Join the carefully selected and tested cash-flow generating program below to potentially create a long-term residual or annuity type income enhancer for yourself.

Traffic Wave - Free Report:  The report will give you all the information you need to start making a nice long-term residual income stream for yourself.