Should a DBA record passwords for application logins, or should this be a responsibility of developers/analysts? By application login, I mean the login which an application uses for access to the database. There will typically be one per application.

I am not referring to user account passwords that are created for users of a system.

  • Do you mean database login for sql server/ oracle security? or do you mean application level passwords, which may be stored in a table inside a user database? – Nick Kavadias Oct 20 '09 at 0:01
  • See update in question. Hopefully more clear. – Sam Oct 20 '09 at 0:18

It is the responsibility of the application developers to keep track of the credentials they need to access the database. Reason being that the application NEEDS that password in order to do it's job, but the database will keep on ticking regardless.

If the developers lose their password, it's the job of the DBA to reset it and provide a new one, but they should definitely not be keeping plaintext versions lying around. Think about a sysadmin and users. The sysadmin doesn't know the users' passwords, and is only responsible for resetting and providing them.


My $.02 here.

The DBA should track the application passwords. The developers shouldn't ever have the production passwords, or the QA passwords for that matter. The DBA should hold all these keys, and give them to the sysadmin who does the deployments as needed.

Personally I've got a little web app that I built a few companies ago which I've found handy. It allows you to put the usernames and passwords into the database, which stores the passwords in a secure encrypted form. All access to the app is logged for SOX auditing.

Access to the accounts is granted via the app so that as the DBA I can create an account and give the developers read access to the account within the app so that they can see the dev password. Same goes for the sysadmin for the QA and Production passwords.

  • Sounds like a handy application. Open source it! Unfortunately our developers change their connection strings in staging and have that migrated to production with an automated procedure - they have the pwds. We audit all object changes, so we at least know what app account is changing what. – Sam Oct 20 '09 at 23:51
  • That's something that I've been meaning to do. But it's one of those I threw it together in 10 minutes kind of things and the code is a little embarrassing. As soon as I can make it presentable, I will be sure to do so. – mrdenny Oct 21 '09 at 1:59
  • that's what pseudonyms are for! too bad we'd all know now if you release it on sourceforge or codeplex! – Nick Kavadias Oct 21 '09 at 6:29
  • Yeah, I'm way to lazy to come up with (and remember) a pseudonym. It'll totally be on CodePlex at some point. – mrdenny Oct 21 '09 at 7:48

In my opinion there should be no need for a DBA to know or get involved with any password that they dont need to know in order to carry out their job. you can help them reset the password when it is forgotten, remind them it hasnt changed/enforce the change cycle and other periferal functions like that but its not your responsibility to be password monitor. It also opens you up to knowing/having access to the password if you are monitoring it.

I would suggest that each application has an application administrator that does this work for their team that way its all managed 'locally'. So long as the account/password combination are monitored for usage so that noone gets anonymous access to the data then it should work out ok.


As with some of the above posts the DBA really shouldn't care or worry about the user/passwords. Unfortunately, someone will need to retrieve this information at some point down the road. We developed a small application that will create the password based on the username using our own algorithm. Us DBA's own the client tool and if someone calls for a password we can retrieve it for them. If in the future the application is compromised we can always change the algorithm and/or reset passwords. We only use this for application accounts.

  • I've also been trying to get rid of the multi use accounts which had popped up before I got here - accounts being used by multiple apps which make a pwd change a crap shoot. – Sam Oct 20 '09 at 23:53

We cannot give you a definitive answer because different answers will be appropriate for different organisations. You should really be having this discussion internally to sort out who should be responsible for the information within your organisation. If you can't come to an agreement on something as trivial as this you probably have other issues to resolve. In a case such as this, what we think should make absolutely no difference.


It's a good question, and probably has as many answers as there are Oracle DBAs. Personally I prefer not to maintain such a list, and will simply set a new password as needed - and possibly set back the original password in it's encrypted form when I'm done.


I think they can. I worked with a company for about 5 years where we had clearly defined roles - the app developers created the apps and designed the database, and the DBAs tested the databases using those logins that the apps used to gain access to the database. They made sure that everything that that user account did functioned as it should, and checked the performance of the database. They did more testing than we ever could. They also made sure all other users were locked out of the database, so anything that happened under that user was restricted to a select few people.

So i actually think it's important to allow DBAs to have those username/passwords. It's just like sysadmins having access to "test" accounts to check certain functions on the network.

  • There is functionality in SQL 2005 that lets you impersonate an account. Set login = 'loginname'. So us actually being able to have those on hand doesn't seem like a big benefit. – Sam Oct 20 '09 at 23:49

It shouldn't be be possible for the DBA or anyone else to retrieve passwords. Reset maybe, retrieve no.

Passwords should be hashed or encrypted in the database and during transmission.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.