Oracle Passwords

[Michael Langas]

I'm looking for opinions with regards to securing passwords for production related accounts, i.e. oracle and related non-users. If my DBAs got what they wanted, they wouldn't have to even use passwords. ;-)

They want me to make it so these passwords never expire, because if they do, it will cause problems with the crons they have set up. I may be dreaming but I think I remember cron running for disabled users.

In any event, I wanted to get some suggestions on a good middle ground. I don't want to compromise security, but I can see why they don't want to have to change and remember 20 passwords every month.

Can anyone recommend a best practice for this sort of thing?

Thanks,

Mike

[Steven E. Protter]

Becausse these two accounts are critical, I don't let them expire.

root
oracle

Its a trusted system though so, three bad login attempts and you're out.

I do however force a password change every 90 days, whether the dba likes it or not.

A good long term solution for you is LDAP integration. You can actually use a Microsoft LDAP server to handle login to oracle apps, shell accounts in HP-UX and your overall network.

One password works all for regular users.

Administrative users such as Oracle will still need separate passwords, but the users of these accounts are IT and can't expect one user id and password to run the world.

On the oracle internal side, we have a minimum password length of six characters, and it must include one capital letter and one number. Every 60 days regular users MUST change their password or they get locked out.

That is our practice. It works for us. Thus far, we've not been hacked even by disgruntled employees on the inside, so it works.

SEP

[A. Clay Stephenson]

An existing cron entry will continue to be executed for an expired user. I just ran this to be sure.

[Kevin Wright]

sure, cron can run for disabled users, but not expired passwords if they have passwords in their scripts, which they apparently do.

You'll never pass an audit if you don't force them to change passwords, at least twice a year.

[Brian Markus]

You can make anyone twist and turn if you bring up a "risk" analysis. If the data gets compromised someone would be really upset I???m sure. Someone has the financial responsibility for that data. You need to show due diligence. If you can???t get them to fix the security problems, make sure you write a memo to them CC???d to two or more people notifying them of the wholes or problems. That way if there is a problem (now a days I should say when there is a problem) you are protected ???CYA???. Make sure your backups are current. I have very strict password policies that I have set in place. Here are some great examples: (http://www.sans.org/resources/policies/). This covers me incase the system I am using is too lame to accept good passwords. If you can go trusted system, do. I also set in place SSH logins and turned off telnet, I make the DBA???s use SUDO so I can track who does what and when, I turned off all rsh stuff, and have an RSA server setup for authentication. I???m not sure how it is in your environment, but in my main production environment there are several clustered database servers, and bunch of middleware boxes, plus a ton of other junk that forms one big system. If the data is corrupt, the whole system is useless. If someone can get one of your DBA???s passwords your toast. They might not alter data immediately, but think if they could run a remote query, they could run a quick select statement like: Select user_name, user_pass, user_ssn, from user_table where user_id = ???5???; you now have a bigger problem. What if there was payroll, bank accounts, or credit card info in that database. You are the Admin, which means you are Administrator!!! Tell them how it is, and put up some walls.

Good luck.

-Brian.

[blal]

Hi

I have a suggestion.Its not adviceble to keep the same password for a long period of time.So trusted mode is highly suggested.

If your oracle user passwords are directly included in shell scripts used by DBAs then its a problem. Solution for that is that keep the passord in some separate file. And in the shell scripts instead of directly putting the password read to a variable.

for example pass=`cat /home/oralce/mypassword'
now the variable pass will get the value (which is password)

where every time when u change the password for the user , update only in this file(ie /home/oracle/mypassword) so you do not have to modify all your scripts manually.Changing one entry will take care of all.

rgds,
baiju.

[Tom Geudens]

Hi Mike,
Our solution may not be the best ... but here goes :
- Users oracle / root are used for installation, run the crontab's and can NOT expire. The passwords of these users are closely guarded by our security forces and only used for disaster-reasons.
- Users ioracle / wroot have the same UID's as their counterparts ... but the passwords of these users have to be activated/disactivated through a menu-system (that uses a service that runs on every system).

This way the right access is available when needed ... but only after authorisation (through the menu-system).

Regards,
Tom Geudens

[Jean-Luc Oudart]

We don't allow people to login directly to "generic" users.
People have to sign on as themselve 1st then su to the generic user.
control and audit in place for these generic users of course.

my 2 (euro) cents
JL

[Volker Borowski · Accepted solution]

Oh oh,

if they do not like to change their Oracle OS account-passwords (which is a very small task), I'd like to know how they handle their database passwords and database network connection ?

sys/change_on_install
system/manager
sapr3/sap
dbsnmp/dbsnmp

If esp. the first and/or the second are default, the guys are right, you do not have to care about the OS password, because the database may be open to any sqlplus-network access as well, without the need for even knowing an OS-user.

They should not only change the OS accounts but the database passwords as well !

As for the OS-Passwords, "sudo" might be a way out. You could allow them a "sudo su - oracle", which will require no password (!), because since "sudo"ed, the "su" is executed as root, and allows YOU to take care about the actual password of "oracle", as they never need to deal with that again.
Of course they have to login with a personal user-id, which should of course be password protected and have a passsword expiration time.

The real benefit is, that you can not check, if Charlie logged in as "oracle", but you can check when Thomas "sudo"ed to the oracle-account because "sudo" logs this. And if the guys do not know the password of oracle, they simply can not log in !

Volker

[Michael Langas]

I'd first like to thank everyone for their responses. I also want to add that most if not all of the safeguards mentioned are already in place. Trusted, SSH, forced password changes, etc... I would like to follow up on a couple of the suggestions however:

A. Clay Stephenson,

I know cronjobs will run. Do you know how /sbin/init.d stuff is affected?

Baijulal,

Your solution sounds like the functionality offered by .netrc files. Does your method have an advantage?

Jean-Luc Oudart,

When you say controls, are you talking about adding something /etc/profile to boot people out if they try to login directly or do you have another method?

Volker Borowski,

I like your sudo suggestion. It would let our security people control the passwords and still be usable for the DBA's. Do you have any suggestions as to how to enforce good database password policy?

Thanks again to everyone.

Mike

[Volker Borowski]

Mike,

you could try this as a starter.
http://www.orafaq.org/faqdbase.htm#PASSWDMAN

Volker