Suggestions for Company Wide Password Vault? 100
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?"
Re:Isn't that idea flawed? (Score:3, Informative)
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.
SecretServer (Score:2, Informative)
Open Source solution -- using Lotus Notes (Score:1, Informative)
It's written by Christian Brandlehner, Jason Engel and Hynek Kobelka. Encrypts the password for the chosen people. Requires the Notes ID to get to it. Very secure. You can control who gets onto the server, then another list of who can get into the application, and finally a third list of who is allowed to see each individual password. The passwords are stored in an encrypted format (for each ID file), so cracking the server does you no good. You can allow everyone in the company access to it, but without the document being encrypted for their ID, they can't tell what the password is. VERY secure.
Since the Lotus Notes client has just been released for Linux, all y'all zealots can't complain as much, though I know the "Lotus Notes UI sucks" people will swarm out of the woodwork.
Oh well. It's good enough for IBM and the CIA to use.....
Cyber-Ark Enterprise Password Vault (Score:3, Informative)
Re:Separate GPG files encrypted to lists of users (Score:2, Informative)
http://www.debian.org/doc/manuals/reference/exampl es/_vimrc [debian.org]
which will automatically encode/decode .gpg files. If you're daring that is.
There is thing called a two-key safe... (Score:5, Informative)
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 (Score:3, Informative)
Seems to me it does everything you need and then some.
Re:Don't do it (Score:3, Informative)
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? (Score:3, Informative)
A recent Infoworld article [infoworld.com] 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:Separate GPG files encrypted to lists of users (Score:4, Informative)
Re:First question (Score:3, Informative)
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.
Physical safe (Score:4, Informative)
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.