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?"
Isn't that idea flawed? (Score:2)
Re: (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
MS Identity Integration Server (MIIS) (Score:2, Interesting)
What you might be able to do is combine the free MIIS and the *ix support in 2003 Server R2 to push
Re: (Score:3, Interesting)
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 th
Re: (Score:2)
Indeed. At my (relatively small) company we attempted to go down the "single sign-on" route as a solution to the plethora of passwords. We quickly discovered that this isn't a magic bullet: as a company that does IT support for other companies, we have accounts on a lot of systems that aren't our own, and thus won't integrate with our directory service. In some cases, we are issued a password and offered no ability to change it. There's also our off-site hosting servers which, since they aren't in the offic
Re: (Score:3, Informative)
A recent Infoworld articl [infoworld.com]
Re: (Score:2)
That's fine for your internal passwords, but having a single password on systems that are less secure - say, those in your DMZ - is risky, especially if it's the same password on your internal systems. If someone hacks just one machine, they'll be able to access them all.
Re: (Score:1)
Take an IT services & consulting company, particularly one that specializes in small businesses.
You build out everything from domains, to webservices, to firewalls, to wifi, to email hosting, and beyond.
Just take the wifi situation, for example (though it generalizes to most of the other cases). You've built the wifi, and you have the admin password to the wap, and documentation about how it is c
How everyone keeps their passwords.. (Score:3, Funny)
Several lockable closets (Score:4, Funny)
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.
ACL (Score:1)
That's exactly what it was designed for.
PHB to the max. (Score:1)
It's current for about 30 minutes at which point it begins to become outdated as passwords are changed.
Good luck.
Re: (Score:2)
First, make sure security policies are sane (Score:2)
As far as a "vault" I suggest an encrypted piece of paper kept in your wallet. I abbreviate made-up words to the first character. If someone can figure out that 23T~ is 23Trimble~ they deserve to get in to my shit.
Re: (Score:2)
Re: (Score:2)
Along with getting new credit cards and so forth I could change passwords. At least there aren't plaintext passwords written down. My personal algorithm shifts special characters and handles numbers differently so anyone finding the paper list in my wallet gets exactly one character from the actual password.
Don't. (Score:3, Insightful)
Re:Don't. (Kerberos can't be used for everything) (Score:3, Insightful)
Re: (Score:2)
Re: (Score:2)
Single Sign-On and Trusted Third Parties don't solve all your problems. As the original poster said, these include database passwords, and will probably include things like passwords for network devices (routers, firewalls, switch management interfaces). These require a password management solution, not SSO or TTP.
There are a couple of enterprise password management products available that can provide ACL controlled access to passwords. They are mostly expensive, and some are inflexible.
A cheaper so
Separate GPG files encrypted to lists of users (Score:3, Interesting)
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: (Score:2)
for our company I wrote a php/oracle system that has minimal permission to view the php source code, and the passwords are encrypted before being sent to the database. the tool is fairly clunky, but it works. took all of 4 hours to write too. people have the ability to create password entri
Re: (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.
Re:Separate GPG files encrypted to lists of users (Score:4, Informative)
Re: (Score:2)
And once you're using GPG ASCII blocks inside regular text files, you can simply dump those individual files into a version control system or central network share. Backups are also dirt-simple, e-mail everything to yourself at some other location or print out the sheets and rely on OCR in the worst-case scenario.
And yes, I'll be looking into "escrow
First question (Score:3, Interesting)
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: (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 databas
Re: (Score:2)
Doesn't handle keeping track of access. Although you could possibly do some fancy stuff with Subversion scripts to track that sort of thing.
Re: (Score:2)
The thing is, that's not really the best way to go about making the originally intended thing happen, and ends up adding another layer of beaurocracy. This used to be a common point of discussion here on slashdot; namely figuring out what you really wanted to do in the first place that prompted the
Re: (Score:2)
I'm not interested in a theoretical information security construct that shows how security could be implemented well. I'm interested in solving the problem I actually have with the systems and equipment that I actually have.
I have minimal control over how much of the individual pieces of equipment are implemented. They d
Re: (Score:2)
Re: (Score:2)
Irrelevant to this problem. Understand the scenarios:
A) fsck has failed during a boot. The machine wants the password for "root" in order to continue.
B) Appliance like an APC masterswitch or an Ironport A60 supports only one password.
Re: (Score:2)
b) write a custom 'driver' that has access to the password, allow selected people to service the APC through the 'driver?'
Assuming the controller is in a room you have some control over, why even have a password?
SecretServer (Score:2, Informative)
Put it in robots.txt (Score:2, Funny)
Easy (Score:2)
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 fil
Re: (Score:1)
Re: (Score:1)
http://www.openntf.org/projects/pmt.nsf/ProjectLo
Re: (Score:2)
The hell we can't. You didn't say a thing about source.
Cyber-Ark Enterprise Password Vault (Score:3, Informative)
Re: (Score:1)
-- neil @ proslink
Physical vault (Score:3, Insightful)
Storing these things electronically is dangerous. Storing them on an electronic box which can be accessed over a network (any network) is just stupid.
So... (Score:1)
Re: (Score:2)
You don't use a combination safe.
You get one of those kick-ass double-turnkey locks like they use for nukes in silos and subs (if movies are to be believed). Then it can only be opened both Sean Connery and one of his top officers are present (or if they've been killed and had their keys stolen by two other guys).
Re: (Score:2)
Re: (Score:2)
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.
If you use an encryption product, use open source. (Score:2)
It's difficult to imagine that it would be acceptable to use an encryption product without having the source code. If you have problems, will you go to Kiev and discuss them with the "high-class" experts? Do you speak Russian?
Suppose a database becomes corrupted, and you need to recover your passwords? Will you send the entire database to the Ukraine?
Suppose the company is now sel
They don't speak Russian in Ukraine (Score:2)
They don't speak Russian in Ukraine anymore. They speak Ukrainian [wikipedia.org]. It's like assuming that the Portuguese spoken by a Brazilian is Spanish. But the rest of your argument appears valid.
Re: (Score:2)
There are about 11 million Ukrainians [ethnologue.com] who speak Russian, out of 47 million.
Re: (Score:2)
However, the point is valid, no matter what language they speak. It is difficult for a company in the U.S. to evaluate such a company.
Re:If you use an encryption product, use open sour (Score:2)
Re: (Score:2)
Shared Passwords BAD (Score:1)
You'd be much better off with a distributed authentication system.
Set up RADIUS/TACACS+ for authentication for all your network devices. I'd suggest Radiator [open.com.au] because it's extensible and reasonably quick, and cheap (not free, but you get the source).
Radiator can do it's password lookups by LDAP (and lots of other things), so you can set up LDAP to keep user's individual passwords. Configure samba, ftp, mail, apache, squid, etc a
Re: (Score:3, Insightful)
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 con
Think disposable vault... (Score:1)
Don't do it (Score:1, Insightful)
Re: (Score:2)
Suppose there's a company that does contract tech support for corporate remote dialin access through a national internet company. Each company's userids are separated under a top-level account, so they have to have a different admin userid on each account.
Since these admin userids are shared with the customer company as well, they can't use the same password for all of them. But each of the techs needed to know what each of the several dozen passwords were, so they could res
Re: (Score:1)
In fact, I think you missed the point. NO passwords should be kept anywhere. If someone forgets his or her password, it's reset, and even the person resetting it does not have access to anything underneath it. The techs don't need to know the password (in our company, if you blurt out a password to a tech, it's an instant password reset, and they all abide by that). The techs never even see the password - it
Re: (Score:2)
On our few clients with only broadband connections, where we were using VPNs instead of using the unnamed national internet dialup network as the intermediary, we did have a modern setup like that. Each tech had his own password, logged into a (web-based) server, and hit a
Re: (Score:1)
Re: (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,
Re: (Score:1)
If I used 1l9a1w6 as a password, would it mean anything to you? Could it be cracked easily? It looks random - well it's my Mother's maiden name interspersed with her year of birth. Next month it could be as6lack0by, which I would find just as easy to remember, but which would confuse most
Re: (Score:2)
I can bet you *used* all of them, and I almost sure you are using at least one of those three *currently*.
I bet more: I bet you don't use more than a dozen of them and then rotate.
Re: (Score:1)
"aslackby" (my place of birth)interspersed with "60" - my current age
"Jeparit" (where I lived for many years, interspersed with the year we moved there.
No, I don't use any of them, but just give them to you as suggestions of how you can generate seemingly random passwords that are easy to remember, but hard for a third party to crack.
And no, I don't rotate passwords - where they really count, I always generate a new
Re: (Score:1)
Unfortunately, if someone does crack your list of words and numbers, feeds them into any sort of password constructor, and then hammers your account to get in, unless it has a set limit of login attempts (and a lot don't) then it will eventually crack it, regardless of how smart you have been in constructing it. That is why it is best to build your password using different "sources" each time, and do it frequently.
Re: (Score:2)
Information security requieres both deep technical knowledge and wide imagination. You seem to lack both of them.
See points 1 through 7.
So you read The Book and you are able to repeat it like a kakatoo. Good for you. Now what?
About point 1: What if the system doesn't allow for multiple administrative passwords (like i.e. a router or a network device)? Do you really want the one password to be known by just one person that can be on vacation o
Re: (Score:1)
No, but at what level is the security of your one-password box? If it requires real security, then if it only offers single password access, it probably isn't the one you want to use.
"About point 2: If it's going to be a one-shot change, then why "res
Re: (Score:2)
This single sentence resumes it all: No, we are not talking about what you think we are talking about.
Specifically, we are *not* talking about just PCs under a single administrative control; we are talking about *any* kind of electronic device under securized authentication/authorization: PCs under the companie's administrative control, yes, but the electronic alarm in the door too, and the whole bunch of routers within our networ
Re: (Score:1)
In all the companies that I have been involved with, I have always been involved on the application software side, and my responses are, of course, application software oriented. The type of hardware (generally) that you are talking about would not fit the same sort of security mould as does the software, and for that stuff, you are, of course, quite right. I have no hardware security responsibilities, and tend to overlook them as "not my worry", I'm afraid. Yo
One password to rule them all (Score:2)
http://en.wikipedia.org/wiki/Single_sign-on [wikipedia.org]
Passwords Max for Groups (Score:1)
We put the the executable and database on a network share (no re
Strongbox (Score:1)
Guaranteed not to lose it... (Score:1)
My suggestion is to post it to http://en.wikipedia.org/index.php/List_of_%5BComp
You'll never lose your password again--guaranteed!
- RG>
All you need is... (Score:1)
Re: (Score:2)
Do it by hand (Score:1)
Whenever you change your password, WRITE IT DOWN, put it in a sealed envelope with your name, the date, and what the password is for. Put it in a secure location where some "keeper of the keys" has access. Preferably the "box" would require two keys to open and would be emptied and the contents put in a vault daily. Just for good measure have 24x7 video recording of the drop-box and the vault.
Re: (Score:1)
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.
Shared Password = Oxymoron (Score:1)
Isn't the FIRST rule of security that you don't ever share passwords?
And the second, and the third?
Structure your access so that the people who would need to access everything in an "emergency" (whatever that might be) have the proper passwords. Then create one MASTER password changed every week and encoded and writen on paper and kept locked in a keyed vault. Then hand out the other passwords structured UP from the users, through the managers, to the V
Token protected database (Score:1)
Enterprise level Password Vault (Score:1)
Cheap solution (Score:2)
First, though I would repeat what someone else posted: using shared passwords is a high risk. It's better to structure your group access appropriately and have people log on as themselves. This way you have a record of who did what and when. Only downside is the number of profiles that get created on servers (Windows), but that's minor.
Vendors for you (Score:2)
Encentuate
ActivIdentity
Passlogix