Suggestions for Company Wide Password Vault?

androidtopp asks: "My company, an IT and business consulting firm of around 150 people, is looking for a Password Vault/Manager/Database solution to manage the numerous passwords we've developed in the course of a major internal network and server upgrade. Our must haves are multiple privilege levels (I don't need to see network passwords, and the network guys don't need to see database passwords, and so on) and it would be nice if we could view when people last retrieved each password. Does anyone manage passwords in this fashion at their work/home? A lot of the free password managers are one user, full access, which is a little less secure than we need. How do other companies (small or large) manage the hundreds of server, network, database, and application passwords that must crop up?"

Comments

How everyone keeps their passwords..

[JDark]

Buy bulk post-it notes and a novelty sized keyboard.

Several lockable closets

[TubeSteak]

Each closet will have a whiteboard.
Each whiteboard will have post-it notes covered in [database/network/other] passwords.

Hand out keys.
Key the locks so that only the people who need to have access to the closeted passwords can open the door.

Problem solved. Right?
And you don't even have to get rid of the post-it notes.

Don't.

[David McBride]

Use Kerberos instead.

Re:Isn't that idea flawed?

[QuantumRiff]

Um, no. That idea is the central idea behind Active Directory and Novell eDirectory. Its much easier to secure one thing, than lots of excel spreadsheets, stickies on monitors, etc..

At my company, we have been working to get everything integrated with Active Directory, so there is only 1 password to manage. Redhat boxes will authenticate against an AD domain now. Just a few more apps to go.

Another solutions is the Microsoft Identity Management server (I think thats its name) that you can actually script password changes. For example, a user does Ctr-alt-Delete and changes their password, then the IM server grabs that, and you script it to connect to your DB, log in as the user, and change password, do the same for web pages, etc. Looks pretty sweet, but we can't afford it.

Separate GPG files encrypted to lists of users

[cblack]

This is what we do for a much smaller group of admins and systems:
Create a simple text file with the systems, usernames and passwords. GPG/PGP encrypt this file to a list of recipients. Now you have a single encrypted file that can be decrypted by any of the recipients. You could break this out into multiple levels by having multiple files, one for each group of "only these users have these passwords" and each file is encrypted to different sets of users.
No logging, nothing fancy, but it just plain works and doesn't require lots of money or time to set up.
One bit of advice: include your web passwords for vendor support or ordering in here as well, not just your internal systems.

Re:Separate GPG files encrypted to lists of users

[crunch_ca]

And as a handy way of editing these files, you can of course set up your .vimrc to include:

http://www.debian.org/doc/manuals/reference/exampl es/_vimrc

which will automatically encode/decode .gpg files. If you're daring that is.

Re:Separate GPG files encrypted to lists of users

[mengel]

There's a script wrapper for this, it's called escrow... We've used it for a while and it's really quite handy.

Re:Don't. (Kerberos can't be used for everything)

[cblack]

Sadly, Kerberos can't be used for everything. Especially logins to systems you don't control such as support and vendor ordering logins that should be available to people.

First question

[Todd Knarr]

The first question I'd ask is, do you need this for distributing passwords to the people who need to use them, or for escrowing passwords so you can get access to them in an emergency when the people who normally use them and know them aren't available?

Re:First question

[Spazmania]

Like me, he probably needs some way to make rarely-used passwords accessible to the staff who need them along with a record of which of those rarely used passwords have to be changed when an employee leaves.

For example, I have switches, routers, PDUs, servers, etc. On the servers I have root passwords, database passwords and so on. The sysadmins need the root password to do a fsck on bootup but that's about it. The rest of the time they use sudo with their own password. The application guys need the database root password once in a while, but only to their servers.

It would be awfully darn convenient if I could say, "Here's a URL and your password to the password keeper. Every password you should have access to is there." Then when an employee leaves I could go to the same password keeper and say, "Show me every password this individual accessed so I know which ones to change."

It would also be very convenient if when my sysadmins finished a new server they had somewhere to log the password in so that the next guy who needed to do an fsck knew where to find it.

Of course, we could just use the same password on everything... But then we're S outa luck when the app guy needs the password to two servers and nothing else.

SecretServer

[FormulaTroll]

There is this: http://thycotic.com/products_secretserver_overview .html

Put it in robots.txt

[Anonymous Coward]

Noone pays attention to that.

Cyber-Ark Enterprise Password Vault

[jeremymk204]

I've used Cyber-Ark's Enterprise Password Vault, it seems extensive as for what it can do. http://www.cyber-ark.com/datasecuritysoftware/ente rprise_password_vault.aspCyber-Ark's website

Physical vault

[whitehatlurker]

When I read this, I saw it as a physical vault - a locked, fireproof box in a secure location in your premises. This is a good idea, especially for important "secrets" which may cause problems if lost. (The password to the payroll system, for example. Your payroll accountant goes into a coma, you might have to get in to make sure that at least you [the IT people] get paid.)

Storing these things electronically is dangerous. Storing them on an electronic box which can be accessed over a network (any network) is just stupid.

There is thing called a two-key safe...

[queenb**ch]

If you're going to do that, it really shouldn't be on line. While I agree that someone needs to be able to get to the "God" passwords in the event of a catastrophic event, our solution to that is very low tech. They are written out on a sheet of paper and placed in a slightly special safe. It takes two keys to open and only a few of us have keys. Some of us have the A key and some of us have the B key.

That way if any of us needs a password to which we do not normally have access, we still have to convince another person to help us open the safe. It provides a secure check & balance with very little inconvienence other than filing away a new sheet of paper once a month.

2 cents,

QueenB

Password Manager XP

[Zocalo]

We use Password Manager XP from CP Lab with a set of databases shared by numerous users across multiple sites via remote network shares with DBs for sites, departments and we also allow individuals to create personal databases if they wish to do so with a quite complex access schema. It's Windows based and not free, but the price is fairly reasonable and the feature set is broad to say the least! You can grant readonly access and update access on per database, per branch, or per password levels as required by to either individual or groups of users. Tip: Locate your password DBs in multiple directories and use Windows' own directory permissions for another level of security, although all common encryption algorithms are supported in combination. It's got full logging, plus a complete change history so you can view prior passwords which is very useful if you dig out a box that's been sitting on the shelf for a few years!

Seems to me it does everything you need and then some.

MS Identity Integration Server (MIIS)

[Anomalyst]

MIIS with foreign export (LDAP, flat file, Novell, etc) is like $25K per processor. However it is free between AD stores including Active Directory Application Mode (ADAM). One drawback is that you cant debug it with VS2005, you have to use older version. Even then I was not successful, the project has been de-emphazised so I haven't had a chance to set it all up again and reporduce the issue with M$ support.
What you might be able to do is combine the free MIIS and the *ix support in 2003 Server R2 to push passwords from AD to a *ix LDAP and sync the non-MS with the LDAP.
I wonder if they are thinking about this in the SAMBAv4 development. It'd be a kick to see them outfox M$ highway robbery.
MIIS FAQ http://www.microsoft.com/windowsserversystem/miis2 003/evaluation/faqs/default.mspx

Re:Don't do it

[LurkerXXX]

Two issues:

3. Passwords must be changed every 90 days (maximum), and there must be a certain length of time before the same password can be reused.

If you want to piss someone off, use a password generator to create a random password whenever the password has to be renewed

While I change mine frequently, and make it extremely random, those two things are going to cause greater insecurity for most of your users. Why? Because they are going to put post-it notes on their desks with the passwords on them, because they won't remember them otherwise. Those two things should make the network more secure. In reality, they don't.

Re:Isn't that idea flawed?

[styrotech]

This isn't really a single sign on need as far as I can tell.

Sure SSO helps out heaps with access control on all the machines on your LAN, but there are a ton of other passwords a typical IT team will need to keep track of that it can't help out with. eg passwords for domain registrars, CA logins for SSL certs, logins for supplier or partner extranets, DMZ or externally hosted servers, any lower end network devices that can't integrate with your SSO system, AD recovery accounts, local admin accounts, all those unix services that can't/won't integrate with SSO etc etc.

Re:Isn't that idea flawed?

[yancey]

And at my business, we use Novell's eDirectory 8.8.1 product running on SuSE Enterprise Linux 9 and Novell Identity Manager to synchronize passwords in real-time (event driven) to Active Directory, other Novell eDirectory systems, Oracle and MS-SQL databases, PeopleSoft and other systems, some in different cities, all secured with SSL connections. Our system holds over 300,000 accounts, with about 60,000 of those being active. I think we expire about 300 passwords a day on average.

A recent Infoworld article ranked it very highly. Novell Identity Manager is very flexible and powerful product and I highly recommend it, especially if you're not a huge fan of Microsoft. Storing passwords in a centralized system is a valid solution as long as your "identity vault", to borrow Novell's term, is properly secured. Personally, I could never feel safe storing all our passwords in Active Directory. Besides all that, I don't have to worry about the critical security patch of the week since it runs on Linux.

Re:Shared Passwords BAD

[Spazmania]

As far as I'm concerned (and It's an informed opinion), shared passwords are BAD.

As far as I'm concerned, you're right. Now, try setting up multiple accounts on an old APC masterswitch, multiple enable secrets on a cisco switch and setting up your unix box to allow multiple accounts to perform an fsck during a unix boot failure.

We live in a practical world man.

Set up RADIUS/TACACS+ for authentication for all your network devices. [...] password lookups by LDAP

Sure, because putting administrative access control for critical network infrastructure behind two layers of complex servers is a winning strategy.

Physical safe

[cdl]

Greetings,

We did this with a physical vault. Each machine's (routers, servers, kerberos domain key (actually stored on a usb key), etc) was generated randomly and printed out and put in a sealed envelope in a fireproof, keyed safe kept in the NOC. They key for the safe was then put in a key lockbox and locked with an "electricians lockout tag" which allows multiple padalocks to lock the same hasp. All padalocks need to be opened to open tke keybox. We used two keys (enforcing a two-man rule) and a security seal. The only way to open it was to open the two padalocks and break the security seal. The security seal number was recorded in the site log. Every shift change, the keys were passed to the site supervisor and another senior person and the security seal checked to insure that the keybox hadn't been opened.

Any time a root password was required the safe was opened (and the fact logged), and the correct password recovered from it's envelope. After use, a new password was generated and placed in a new envelope. At each safe closing, an inventory was taken to insure that all the envelopes were there.

A bit paranoid, but we certainly passed our auditors requirements.