Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Within an organisation there are many passwords such as those for root accounts on servers, hosting accounts, router logins and other such things, that need to be kept track of.

I know in some organisations its a case of either the head of IT only knows these passwords, the passwords are written down some where, stored on a wiki behind a login, or passwords are stored in a file on a server (perhaps encrypted).

My question is simply what is the most effective way of managing these password and storing passwords in a secure way. I know this topic has previously been discussed in regards to a home user here, but I am specifically interested in the best way to go about it for medium to large businesses. I would also be interested to hear what approach has been used within other peoples organisations even if its not the most effective.

share|improve this question
    
To clarify, are you talking only about privileged users, single/shared users, or user/identity management in general? –  AviD Nov 23 '10 at 12:57
    
My apologies I thought that I was clear enough. I'm talking about account details for system and devices that a user can't have their own issued for and can't be be managed using other login system as have no control over them. Privileged users should be able to access the passwords but other people obviously should not be able to. Hope that makes more sense. –  Mark Davidson Nov 25 '10 at 11:05
    
So, shared users / single-user-mode, then. Indeed, different problem... –  AviD Nov 26 '10 at 8:22
    
I'm still looking for a really good answer to this question so have added a bounty. To make sure its absolutely clear I am looking for a solution that will store passwords for devices/programs that require you to use a password, even if you dont want to. E.g routers, some firewalls, hosting accounts, etc. These passwords should be accessible to admin staff only. –  Mark Davidson Nov 27 '10 at 19:50

9 Answers 9

up vote 9 down vote accepted
+50

Although I've seen many implementations of solutions to this problem, I believe that the most complete, if not perhaps the most convenient, was a Git repository restricted to super users only containing encrypted text files of passwords by environment. Managing the password rotation on the devices, mixed servers and dedicated devices such as modems, was handled separately.

This solution greatly simplified the distribution of new passwords as a simple update needed to be performed by users to receive the latest revision of the passwords as well as providing a traceable history of previous passwords for record keeping.

As I recall the files were GPG encrypted, but there are numerous solutions and viable approaches to handling the files themselves.

The obvious downside to this approach is that, especially when passwords have changed, you are decrypting one or more files searching for the required password(s). Of course, as with anything, the more frequently you use a password the more likely you are to memorize it and, depending on the device(s) in question, access may be an infrequent event which is not greatly hindered by having to go through a somewhat more lengthy process to gain the appropriate password.

If you are also interested in strategies and/or scripts for generating and/or changing passwords on servers and/or other devices I would be glad to share those that I employ as well.

--

I would be glad to.

I will assume that you are familiar with file encryption, PGP or otherwise. If this is erroneous please feel free to ask and I will be happy to provide some examples.

Setting up a Git repository is relatively straightforward and will display similarities to most any content management solution with which you may be experienced. One note with Git: it is, by design, fully open and, as such, will require additional steps to restrict access to specific files or repositories. This can be accomplished relatively simply by leveraging file system acl's (just one possible solution). That being said, I would certainly recommend that you use a solution with which you are comfortable and familiar, especially if alternate content management solutions are already in use at your organization.

The file(s) will, by definition, represent a password database correlating device identifier(s), such as hostname, to passwords and, potentially, to user names. For example: router-1.internetdomainwebsite.com administrator soopersekretpasswerd. Ideally you will never store the file unencrypted, however, following this strategy does make retrieving passwords relatively inconvenient. For this reason I recommend scripting an accessor to work within your encryption framework, perhaps taking an identifier as a search term and writing only the requested password to a file for one-time use by the requester.

Any device that supports password changes can be scripted. Since most devices support changing passwords from a CLI, I would recommend taking a look at the Expect language and/or its libraries for Perl, Python, or the language of your choice. I personally use a script that accepts the desired username, accepts the current password, accepts and verifies the desired password, then changes and verifies the change on all hosts passed or provided when prompted. Its fairly bare-bones Perl with Expect.

share|improve this answer
    
+1 Great answer Tok, sort of thing I was looking for when I asked this question. I was thinking of a similar system. I would be interested in seeing anything on the topic that you are willing to share. –  Mark Davidson Nov 29 '10 at 14:26
    
@Mark Davidson - Please let me know if you would like any additional details or suggestions on any aspect(s) in particular. –  Tok Nov 30 '10 at 13:16
    
thanks for the additional details will give it a look over. –  Mark Davidson Nov 30 '10 at 23:29

Passwords are the problem, not the solution. The general problem is secure authentication and authorization, often viewed as part of "Identity Management".

LDAP or Kerberos/AD can be used to centralize authentication and keep passwords in sync. Using SSH and public/private key authentication is another good option.

The most modern approach is to solve that problem in a more general and convenient way, that also helps folks to move from passwords to secure tokens or other more robust ways to authenticate. A single-sign-on system that allows people to authenticate once and then leverage that authentication for authorization to access other services is a common solution.

Technical approaches for doing that include OAuth, SAML, Shibboleth, and InfoCard.

share|improve this answer
1  
While I like what you wrote, I'm not sure this is a direct answer to the question, or relevant. See my comment uptop. –  AviD Nov 24 '10 at 15:36
    
@avid Perhaps the answers are different for medium and large enterprises. Medium ones that are not IT-focussed may find it acceptable to use individual passwords for access to lots of IT resources, and need a way to manage them. But if a large enterprise was still doing that I'd be scared. At any rate my point is that more and more we're finding convenient ways to get away from passwords, which can be a real liability. But my response isn't yet really very helpful in a concrete way.... –  nealmcb Nov 26 '10 at 6:41
    
perhaps my edit helps a bit. –  nealmcb Nov 26 '10 at 6:47
3  
Yes, btter now - but unfortunately there are still many devices/programs that require you to use a password, even if you dont want to. E.g routers, some firewalls, hosting accounts, etcc - from the question. –  AviD Nov 26 '10 at 7:06
1  
And the other problem with single-sign-on is that their ordinary user account suddenly gains admin privileges because SSO doesn't do elevation of privileges very well, if at all. In addition it doesn't help for secure systems where you want to control access through a combined authentication were it takes two or more people working in combination to authentication (your usual break glass scenario) –  blowdart Nov 30 '10 at 2:30

As per your comment, that you're talking about systems and devices that insist on shared users / single-user-mode:

First off, try to avoid / minimize this as much as possible.

Second, avoid and minimize this as much as possible.

Third, this should definitely be a consideration when evaluating products/services - if it has such an inherent insecurity, you might not want it after all. It's likely that there are other issues there too...

Fourth, double check with the vendor/provider to see if there is a way to configure it securely.

Fifth, consider building a thin "proxy" type application, that will enforce user authentication, and then use its own single account for the device, with its own internal random password.

Sixth - if aaaalll the above are not relevant / don't work (seriously??) - I have seen places that have an ACLed, encrypted folder - or better, a cryptosafe - with access granted only to the admins, and in it stored file/s with the randomly generated passwords.
Depending on your culture/type of org, it might be better to print out the passwords and store them in in ACTUAL safe, protected by your security officers, and the combination given only to the admins....

share|improve this answer
2  
+1 for "print on paper and store in a physical safe". Honestly, this solution should be used more often than it is. In many (chaotic, resource-constrained) smaller companies there is more economic damage done from being slow to fix server / device downtime than there is from getting hacked by a human intruder. –  Jesper Mortensen Apr 19 '11 at 7:59

Root passwords and Administrator accounts of all types should be done in the following manner:

3 key stakeholders assign them randomly with maximum-sized very pseudo-random assortment of characters.

They write them down (without memorizing them) and put them in envelopes and store/secure them safely. They rotate them every year with new passphrases.

Daily use is done via group administrator accounts tied to real names, separating contractors by both account name (e.g. admcjsmith instead of admjsmith) and domain (if possible). Unix/LDAP is done in a similar fashion e.g. via sudo.

Named accounts like root and Administrator should never be used or known. In a similar way, cloud Access key / API key accounts need to be compartmentized and secured.

share|improve this answer

We use KeePass to store the passwords. Each team lead in IT (Security, Systems, Clinical, Business, Ancillary) is responsible for their teams KeePass database and maintaining the contents. If anyone with access to a given database leaves the department or the organization all passwords in that database must be changed.

I have seen and reviewed applications that proxy the authentication to support auditing and password management. These worked for some of our more common applications, but did not address the industry-specific applications we use.

share|improve this answer

I've worked with "Secret Server" at http://www.thycotic.com/ . I can provision a single password and share it among as many or as few individuals as I want.

There is an audit trail, and a great search functionality built into the web application. There is also an online "cloud" version of the application that is free for one user.

You can create a new secret for each device you own, and add your own as needed:

Security Choices

All access to this database is secured by local, or Active Directory credentials. If you choose to do so, you can have seamless login (SSO) to access the database for the currently logged in user over Kerberos/NTLM.

Overall, I think this is a good choice for a team, and general repository for corporate security information.

share|improve this answer
    
You wrote this response to several questions -- if you are in any way affiliated with Secret Server, you might want to indicate that. –  Christian Severin Sep 26 '11 at 11:24
    
@Christian - I'm only a consumer and advocate of the product, and have yet to see something comparable. In fact I think I only had contact with them though thier support department once. –  makerofthings7 Sep 26 '11 at 17:33

I really like Password Manager Pro. Its a website that is tied to your ad/ldap that will share out passwords to your organization to whatever grouping you want, people can also store passwords of their own.

It will does some solid policy work, historics, audits, and what not.

It also has change capabilities, I have wired up some nice pam scripts to do some changes right from PMP that would have been pains to do otherwise.

Some of the hard passwords, like your network solution password, a helping hand remote datacenter passwords and stuff like that, it has some canned logic for that can be tuned. Amazing when you get all that work done to see how much you have hanging out there and how much you should have more / multiple sets of users and so forth.

share|improve this answer
    
See this question: security.stackexchange.com/q/279/33. Of course here its even more so, if you're talking about corporate credentials... –  AviD Nov 23 '10 at 22:16

I agree with nealmcb that in a controlled environment with competent administrators a single-sign on solution is probably the best.

For tracking credentials for 3rd party websites or services you could have a look at lastpass.com's enterprise solution which allows you to share logon credentials with users and specific roles.

I have also heard "Clipperz" mentioned in this context before but I have no experience with it.

share|improve this answer

Passpack seems to be a service developed exactly for this purpose. It allows storing password (and other info) online in encrypted form and share rights to passwords within a team. Also supports one-click login by browser bookmark script.

I don't have yet any experience of using it. But after doing small research on the topic today Passpack looks a like the solution we're going to use in our 7-person team.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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