Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

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?"
This discussion has been archived. No new comments can be posted.

Suggestions for Company Wide Password Vault?

Comments Filter:
  • Seems to me, saving every password in a company in a central location would be the first place any hacker would go after.. and should they gain access.. you can say goodbye to that company.
    • Re: (Score:3, Informative)

      by QuantumRiff ( 120817 )
      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
      • 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
      • Re: (Score:3, Interesting)

        by styrotech ( 136124 )
        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 th
        • by Nurgled ( 63197 )

          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)

        by yancey ( 136972 )
        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 articl [infoworld.com]
      • by Dadoo ( 899435 )
        get everything integrated with Active Directory, so there is only 1 password to manage.

        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.
    • by Allador ( 537449 )
      There are certain industries or business types that need this, however, and his (and mine) are of this type.

      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
  • by JDark ( 512354 ) <johnathandark AT yahoo DOT com> on Wednesday September 13, 2006 @06:38PM (#16099997)
    Buy bulk post-it notes and a novelty sized keyboard.
  • by TubeSteak ( 669689 ) on Wednesday September 13, 2006 @06:39PM (#16100008) Journal
    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.
  • you can fake it with Linux and sudo (or multi-group support), or Windows ACLs.

    That's exactly what it was designed for.

  • Sounds like a PHB came up with that. It's the same thing that a PHB I used to work for did. CIO puts all passwords into an Access database that is password protected then places it in his own, higher level private share on the network. Each password is actually entered in a "secret" code that all IT employees are aware of just in case it is hacked. The CTO also has access to this database.

    It's current for about 30 minutes at which point it begins to become outdated as passwords are changed.

    Good luck.
  • If you are requiring complex passwords that expire every 30 days, maybe a more relaxed approach will enhance security. It's more secure to have a sane policy than to have stickies with passwords on every monitor.

    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.
    • That reduces the complexity of the password to the complexity of the word, and defeats the purpose of including numbers and non-alphanumeric characters.
      • Well, assuming I lost my wallet, I have lost unencrypted credit cards and cash and have real problems.

        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)

    by David McBride ( 183571 ) <david+slashdot@dwm.[ ]uk ['me.' in gap]> on Wednesday September 13, 2006 @06:42PM (#16100028) Homepage
    Use Kerberos instead.
    • 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.
    • by Twylite ( 234238 )

      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

  • by cblack ( 4342 ) on Wednesday September 13, 2006 @06:42PM (#16100031) Homepage
    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.
    • the issue here is when you dont have a person who know's all... a typical sccenario, most DBA's are precious about their systems and passwords, and dont want sysadmins knowing the passwords they control, and vice versa..

      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)

      by crunch_ca ( 972937 )
      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 [debian.org]

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

    • There's a script wrapper for this, it's called escrow [www-zeuthen.desy.de]... We've used it for a while and it's really quite handy.
    • I'll second GPG. Although I prefer to keep each system in a separate file (makes it easier to look at the change dates and see when things were modified).

      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)

    by Todd Knarr ( 15451 ) on Wednesday September 13, 2006 @06:53PM (#16100103) Homepage

    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)

      by Spazmania ( 174582 )
      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 databas
      • GPG encryption inside regular text files (one per service) stored in a version control system. The contents of the files are encrypted using the public keys of everyone who is supposed to be able to decrypt the file contents. Unfortunately, it probably won't scale past a dozen users.

        Doesn't handle keeping track of access. Although you could possibly do some fancy stuff with Subversion scripts to track that sort of thing.

      • Sounds like you're making things complicated. You've got one thing you want to do: everyone has access to the things they're supposed to, and this idea about implimenting it using some kind of password database.

        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
        • How does any of that help me put the root password for a boot-time fsck in the hands of the sysadmin at the console without everyone having to learn a new password every time someone leaves?

          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
      • by cmarkn ( 31706 )
        It sounds like you want to do something like this [linuxgazette.net]. That way, you have a separate root account for each person who needs it, and you just delete the account of the person who left. No one else ever knows or cares that anything changed.
        • Been doing that since '92. Sudo is also applicable.

          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.

          • a) remove drive, insert fresh drive with the standard image, restart server.
            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?
  • by Anonymous Coward
    Noone pays attention to that.
  • Just have everyone use a blank password for everything then you don't need any fancy vaults.
  • by Anonymous Coward
    http://www.openntf.org/Projects/pmt.nsf/ProjectHom e?ReadForm&Query=Open%20Notes%20Picture%20Database [openntf.org]

    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
  • by jeremymk204 ( 939483 ) on Wednesday September 13, 2006 @07:13PM (#16100199)
    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.asp [cyber-ark.com]Cyber-Ark's website
  • Physical vault (Score:3, Insightful)

    by whitehatlurker ( 867714 ) on Wednesday September 13, 2006 @07:21PM (#16100236) Journal
    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.

    • where do you store the combination for the safe?
      • No, no, no.

        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).
      • Any safe can be opened. It's just a matter of how long.
      • C'mon - somebody mod up LordEd. It deserves at least a funny, if not insightful.
  • by queenb**ch ( 446380 ) on Wednesday September 13, 2006 @07:28PM (#16100272) Homepage Journal
    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,

  • Password Manager XP (Score:3, Informative)

    by Zocalo ( 252965 ) on Wednesday September 13, 2006 @07:45PM (#16100342) Homepage
    We use Password Manager XP from CP Lab [cp-lab.com] 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.

    • Quote from the CP Lab About Us [cp-lab.com] page: "Our company is located in Kiev, Ukraine. CP Lab's employs high-class experts, ..."

      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
      • If you have problems, will you go to Kiev and discuss them with the "high-class" experts? Do you speak Russian?

        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.

        • by sco08y ( 615665 )
          They don't speak Russian in Ukraine anymore.

          There are about 11 million Ukrainians [ethnologue.com] who speak Russian, out of 47 million.
        • My understanding is that almost all educated Ukrainians speak Russian as a second language.

          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.
      • Yes, open source would be better, but since so few people *really* understand encryption to the point that they could take a look at the source code and say "yes, that's secure" most people would still be relying on someone with the necessary skills monitoring the code. You can't just assume that because the code is available that all the specific code versions in your compliation has been checked and found to be backdoor free by someone capable of doing so. If you need the open source comfort blanket tho
      • Don't fall into the trap of the technical mind; we're talking about a business, here. For business and audit purposes, whether the product actually works as advertised is nowhere near as important as whether the purchasing authority did his due diligence (and can convincingly say he had every reason to believe it didn't have a back door built in), and whether the vendor officially supports the featureset the purchaser will be using (which means they, not the purchaser, can be blamed when the product fails t
  • As far as I'm concerned (and It's an informed opinion), shared passwords are BAD.

    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)

      by Spazmania ( 174582 )
      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 con
  • Get a metal box. Put a thin slit in it incase passwords are ever updated. Weld it shut. If it's important enough that someone needs to retrieve the password, then it's important enough to break open the box.
  • Don't do it (Score:1, Insightful)

    by JoGlo ( 1000705 )
    Part of my responsibility is related to information security, and as such, I have been exposed to a number of propositions related to password security. The bottom lines are that: 1. No two people should EVER share a password -passwords must be individual, otherwise they have little or no meaning. 2. Every time a password is reset, it must be a "one-shot" reset, forcing the user to change it again before he/she can use it 3. Passwords must be changed every 90 days (maximum), and there must be a certain leng
    • by hob42 ( 41735 )
      I think you're missing the point.

      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
      • by JoGlo ( 1000705 )
        Funnily enough, we could be working in the same company. Multiple clients spread over 3 continents.

        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

        • by hob42 ( 41735 )
          Problem in our case was, we didn't have control over the network the userids were created on, nor did we have control over the terminal software we used to connect to it. We're talking stuff that's got at least 20-30 years of legacy in it.

          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
          • by JoGlo ( 1000705 )
            Ah, so, security-wise, you started out well behind the 8 ball, by the sounds of things. Not much you can do if the architecture doesn't allow it, but even then, the next releases shoul, with the hackers and nasties out there today, move towards more modern prevention techniques.
    • Re: (Score:3, Informative)

      by LurkerXXX ( 667952 )
      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,

      • by JoGlo ( 1000705 )
        Then your rules for the construction of passwords is not well enough described to give the user the latitude they need without allowing them to use their wife's maiden name or youngest daughter's pet name as the password.

        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

        • "If I used 1l9a1w6 (...) Next month it could be as6lack0by (...) how about j2e5p9a1rit"

          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.
          • by JoGlo ( 1000705 )
            "law" interspersed with 1916, my mother's maiden name interspersed with her date of birth

            "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

      • by JoGlo ( 1000705 )
        Yes, I can see that this may work.

        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.

    • "Part of my responsibility is related to information security"

      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
      • by JoGlo ( 1000705 )
        "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 or under the mythical overuling bus?"

        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

        • "Sorry, we're talking real applications with keyboards here, not POS machines"

          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
          • by JoGlo ( 1000705 )
            Ah, now I understand your comments. Thank you.

            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

  • Search for it, authord.com is apprently dead or broken. Not affiliated with them, have used it for a couple years. Does NOT integrate with AD. Keeps a local list of users/categories/groups you can assign access levels and if they (or their group) are not assigned to the category or their access level is too low, they do not even see the entries. Windows only, written in VB, $129 for 10 users. I haven't found any viable open source alternatives.
    We put the the executable and database on a network share (no re
  • I actually borrowed an idea from a previous employer (tho wrote my own implementation), called StrongBox. it's a mysql database AES encrypted messages (containing passwords, messages, etc), the key is a SHA-1 has of a request ID and their employee ID.. it works rather well, it's all php/mysql and a little bit of javascript
  • One problem my organization has is we keep forgetting passwords that are rarely used.

    My suggestion is to post it to http://en.wikipedia.org/index.php/List_of_%5BCompa ny [wikipedia.org] Name]'s_Passwords

    You'll never lose your password again--guaranteed!

    - RG>
  • Lots of little yellow postit notes stuck on your monitor.
  • I did this informally but there's no reason it can't be done formally.

    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.
    • Two envelopes. One contains the list of devices+username. The other contains the number of the correlating entry in the first envelope and the password. Envelopes are kept in two seperate locations. Fact of password retrieval is logged and/or requires authorization from PHB, etc.
  • Physical safe (Score:4, Informative)

    by cdl ( 902729 ) on Thursday September 14, 2006 @12:43AM (#16101650)

    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.

  • I know this first part is off-topic, but stick with me.

    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
  • Just a thought: If you've implemented an RSA tokens for dialup/vpn access you may be able to use them to authenticate to a ssl webpage tied to a database containing the passwords. Don't know if Java, .net, etc can hold them in protected memory, you may have to write a client side app for that. Or I suppose you could just risk other processes reading that memory segment.
  • Here is a product that was demo'd to a network security company I used to work for. IT is an enterprise level PW fault that would accomplish what you are looking for and might add some levels you didn't think of. http://www.cyber-ark.com/networksecurity/passwordv ault.asp [cyber-ark.com] No I don't work for them I saw the post and remembered the demo.
  • I did something like this at a previous job though we only had three of us in IT that could access this. You could adjust it for your tiered environment.

    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.

    1. Create a secure ne
  • The following companies will be more than happy to sell you a password storage/single sign on solution:


It is not for me to attempt to fathom the inscrutable workings of Providence. -- The Earl of Birkenhead