Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I don't want any tools, but more methods to help us manage our passwords.

I know this question has been closed, but I think this one, even if it's related, is more a programmers problem than a super user problem.

We are using some database schema, each with a password. These schemas exist in our 4 different environments (DEV, TEST, INTEGRATION, UAT)

There are corporate rules about passwords, so we need to change them often. Wrong passwords result in locked accounts. This happens quite often and takes countless hours to be solved by dbas... The rules are also quite drastic about how to change a password. No re-use, some word forbidden... The result of this setting is a very often unusable database for our dev. And lots of frustration too.

Do you know any 'deterministic' way of creating passwords that can help us to avoid total mess?

share|improve this question

closed as unclear what you're asking by MichaelT, gnat, Snowman, Bart van Ingen Schenau, GlenH7 Jun 15 at 20:03

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

6 Answers 6

I would recommend what I always recommend whenever a user name/password issue arises -- get out of the username/password business if possible.

In your case the problem is that devs have passwords for the database, devs should be in a GROUP that has the appropriate permissions.

Why have a password, when you can use something better?

share|improve this answer
"something better"... like what? RSA key auth, or? –  hd. Jun 12 at 8:08
@hd.: that depends upon details the OP didn't provide. Probably windows and AD. –  jmoreno Jun 12 at 11:50

You don't say which DBMS you're using.

If it's SQLServer, or anything else that can talk to your Active Directory, then Domain groups are the way to go. Given the group the [database] permissions it requires and add/remove Developers from the relevant group(s). Clean and simple and removes the need for local, Developer accounts in each database.

As others have said, separate your application credentials from Developers.

I would argue that Developers should never have access to application account credentials. If they need access to a database (and that should be a "big if", BTW, not by default) then they should be given access to it in their own right, through a process which is properly authorised and audited.

Do you have different levels of [Developer] access in Dev, UAT and Production? Say update, maybe even DDL, in Dev, DML in Integration, Read-only access to UAT, and nothing at all in Production? If not, why not?

Why should any Developer, writing shiny new functionality, need access to, say, your Production Customer list? OK, if they have a support Role (as well) then they might do, but someone has to make that determination and stick to it.

share|improve this answer

Use a strong password generator that allows you to save them in some sort of local encrypted vault. I used to recommend Last Pass for web passwords but I can't recommend a hosted service for highly confidential internal passwords, especially given recent events. I now recommend http://keepass.info

share|improve this answer
Thanks, but I don't want a storage tool: I'm looking for a method that help every dev to remember what is the password for any db at any moment without relying only to its memory –  Guillaume May 6 '11 at 15:21
Wait, you want "a method that help every dev to remember what is the password for any db at any moment without relying only to its memory" but you don't want a tool that will store and retrieve passwords? I don't understand. –  Rein Henrichs May 6 '11 at 15:23
@Guillaume - I use a system when I create a password. Of course by doing so I make the password less complex. I would of course argue that a 16-24 character password even if its less complex can still be secure. It helps me remember my passwords at the very least. What you want could easily be solved by a program that encrypts a developers huge list of passwords for them which means a single password they have to remember. Roboform has a mobile version that worked for years. –  Ramhound May 6 '11 at 15:48
I have been reading your answer to fast. The LastPass evocation may have trigger a skip this answer reflex... But your suggestion is good and keepass.info looks good. –  Guillaume May 9 '11 at 9:07

What you should really do is separate the un/pw that the application is using from the un/pw that the developers are using.

Most corporate policies allow "application only" user names and passwords to have an extended expiration period as long as you can prove that only the application will use those credentials. This way you set them and store the credentials in a secure location.

It's bad practice to let your developers and your application share credentials. Give your developers their own credentials (one login per user) and let them manage their own passwords just like they do for their network accounts.

By using a "method" for setting and remembering passwords, you are just breaking down the security the passwords are trying to protect.

share|improve this answer
I'm not deciding for what the rules are... I just forced to follow them.. My problem are more related to database usage than generic application, and I never see dev having their own username/password in this area...Having a "method" is also a way to reduce password being sent around in mail/chat every days and to avoid each one storing a password list in a txt or excel file... that is breaking the security more than having a secure way of remember the passwords. –  Guillaume May 9 '11 at 8:57

This problem can be designed away from most systems. It also is probably a question best asked on SuperUser.

For example, if you have a client/server design for your application, you should be able separate out the database password management code into a module on the serverside portion of the application. Ensure that the serverside portion stores and manipulates the password according to appropriate policies. Require that developers log in to the application with secure un/pw combinations. It's also generally in poor form for database credentials to exist anywhere other than the server tier.

Consider configuring the database server to use LDAP or other existing authentication methods for authenticating the developers, rather than a system that's implemented by the database vendor. The benefits are going to go beyond just solving this specific problem.

Other options are available, ala the LDAP option, which are best asked for on SuperUser - ask there about methods to configure applications for development use under strict, corporate, security and password requirements.

share|improve this answer
I'm not sure my question is very clear... The problem is not when accessing the db from the application. It's occurring when developing the application: as dev we have to log in the db for maintenance: prepare update db schema, data clearing, whatever sql scripts that will be run by the prod on release. This is when the problem arise: when logging to our dev/uat databases with our db tools (toad, sql developer, eclipse plugin, sqlplus, ...) to prepare and tests these scripts. –  Guillaume May 9 '11 at 9:10
use local copies of the database for development work (SQL Express), and design the rest of the functionality into the server side components of your application. –  blueberryfields May 9 '11 at 20:30
Yes, that's a good suggestion..; I'm just trying to install it without admin right and it is not so easy... Damn group policies! –  Guillaume May 10 '11 at 8:21

Do what SLoret suggests. Another trick would be to get the development stuff "off the reservation" so to speak -- we keep our QA/UAT on a separate network that is really managed by development so we don't need to deal with rigmarole like this.

share|improve this answer
we can't choose to host our own QA/UAT... –  Guillaume May 9 '11 at 9:02

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