Database profiles

My first rant on this blog might as well be one of my favourites, although regrettably a bit long...

I frequently see on customer sites database profiles implemented for application users but not for database administrators or default accounts (e.g. SYS & SYSTEM).

Okay basic refresh: Database profiles enforce resource and password restrictions on database user accounts. It’s these password restrictions that are essential for securing your database. They allow you to lock accounts after a number of failed login attempts, force the user to select a complex password, restrict the user from reusing passwords and force the user to change the password after a period of time.

All good stuff right? Well apparently not, and it all comes down to that last one; forcing regular password changes.

Many DBAs are responsible for tens (and in some cases hundreds) of databases and therefore have to memorize more passwords than is required to launch Global Thermonuclear War. Then some auditor comes along and informs them that the new company password policy is that accounts must lockout after 4 failed login attempts and passwords must be alphanumeric, at least ten character in length and changed every 30 days and never reused. The DBA's brain then starts to melt at the thought of changing and memorizing hundreds of passwords every month, and instantly starts to object to the auditor. After a slightly heated discussion they come to a compromise; the DBA will happily inflict any draconian password restrictions on his user base as long as it doesn’t affect accounts he has to use.

But wait a minute; haven’t we just thrown the baby out with the bathwater? Isn’t locking accounts after failed attempts a good thing? And password complexity and reuse restrictions? Somehow the DBA who’s so horrified at the thought of memorizing hundreds of passwords every month, has somehow inseparably fused all these facilities together and is refusing to have any password controls on his administrator accounts.

“Surely not!” I here you say. But it’s true! I’ve been there when the mere mention of database profiles on administrator accounts has turn the DBA into a red faced, spitting, fist banging daemon, shouting “WE’VE BEEN THROUH ALL THIS WITH THE AUDITORS! WE’RE NOT CHANGING ALL THE PASSWORDS EVERY MONTH!” He also becomes completely deaf to any sensible or reasonable suggestions made for the rest of the day.

The solution of course is obvious and I hardly need explain it; but if you don’t have database profiles enforcing password controls on your administrator accounts then do it now, if forcing regular password changes is an issue then leave it out for now. Not that I am endorsing static passwords by any means, but it’s better to have some password controls on your administrator account than none at all.

As part of the ongoing efforts by Oracle to improve database security out of the box, Oracle10g release 2 has FAILED_LOGIN_ATTEMPTS set to 10 by default. As far as I am aware, no one has actually burst a blood vessel when they first hear about it.

But seriously, I appreciate that DBAs don’t want to change every password every month but if you don’t enforce regular password changes (either by database profiles or company procedure) at least once a year, then those passwords will remain unchanged for years.

One neat solution I once read was to have a password for each system that changed fairly infrequently and a global password that changed once a month and concatenate them together. For example system1’s password may be “Redwood4Helium90” and system2’s password might be “Seriously55Helium90”. The following month the “Helium90” part of the password is changed to “GreenIron2” for all systems. This way each system password is unique, it is changed every month and no-one’s head has to explode.

Sounds like a “Win-win” to me.