Storing lots of passwords that different levels of employees need access to

Question

I am wondering what other people do for storing passwords. Our current model at my employer is fundamentally flawed in my opinion, so I am trying to see what other people do so I can select the best method.

Right now all of the passwords for everything are stored in an excel file that is in a password protected Dropbox folder. Only a couple people have access to it.

Certain employees need access to different passwords and some of them are near impossible to remember while others are simple dictionary words with some punctuation and numbers attached for easy remembering. So the marketing department needs access to certain passwords that the accounting department does not need access to and vice versa, this goes for several departments as well.

Some problems I see are that the passwords are not encrypted, there are a couple gatekeepers that have access to all the passwords, not only is it an inconvenience for those people everytime someone needs a password but its also another security risk. I could keep going on about the flaws in the current setup. I am curious what other people do in this type of situation?

A solution I was thinking of is creating an internal intranet database that is encrypted and each time a person needs a password they login and can select the password they need. The CEO or person in charge can change the passwords, decide who gets access to what passwords, etc.

Answer 1

First off, for as much as possible you need to switch over to something like Windows Active Directory or using LDAP* for internal permissions. That way, users get permissions based on a central repository, don't know other users passwords, and you can audit who is able to - and who did - access what.

I'll assume you aren't in a regulated industry (if you are, you're in real trouble). Even then, your company's current setup shares all the passwords with Dropbox, anyone who has access to Dropbox data or backups, and potentially with any company that later merges with or acquires Dropbox. This may or may not be an argument anyone cares about.

Changing passwords is a big deal, and any time anyone leaves, you SHOULD be changing passwords - why does someone not employed or under contract have access to corporate resources? It's even worse if they left under less than amicable circumstances.

After you're done with the AD or LDAP integration, there will still be systems that aren't integrated. For those, I'm a big KeePass** fan. Employees can have a "personal" KeePass file, which is their primary, and holds person-specific accounts - which should be used as much as possible, so they can be disabled when people leave and so actions can be audited

• You SHOULD monitor for, and take serious action when you see employees sharing passwords. This is a very common practice in small unregulated companies, and it causes problems later (audits failed, clients asking hard questions on their own audits, future regulation, and again the cost of changing every password any ex-employee knows).

• If your employer really loves Dropbox, there is KeePass integration available, as well as FTP, SFTP, etc. integration.

  • Ask them what their plan is for times Dropbox is inaccessible (being DDoS'd) or suddenly goes out of business (if Enron, Lehmen Brothers, and Lavabit can vanish overnight, so can Dropbox)

Employees may also have shared KeePass files if absolutely required - it does a good job of handling a few people opening and modifying the same .kbdx file simultaneously, merging the updates, or you can use the Synchronize command. The passwords and keyfiles used to open these shared KeePass files should be kept to as few people as possible, the contents should be kept as minimal as possible, and you again change passwords and keyfiles whenever someone that knows them leaves.

• Again, set up individual accounts at every point that can be done. When you have to investigate something (call it a production problem, or maybe fraud), this is critical.
• For any shared KeePass databases, use both a randomly generated keyfile if management agrees to it, but also long (35 character or more) passwords generated randomly by KeePass itself; employees keep the shared passwords in their personal KeePass database, and the passwords MUST be so long and random that it's honestly burdensome for employees to hand-type them.
  • That way, there's no incentive to write it down; it takes forever and it's a pain to type anyway.
  • High ASCII characters can also be used, like the copyright symbol or accented characters, making it even more difficult for employees to get in the habit of using shared superuser accounts without going through their own KeePass document.

*For a linux example, see the question "how do I configure my RHEL5 or RHEL6 system to use ldap for authentication?"

** When you set up your KeePass database, or afterwards if someone else does, make sure to go into File, Database Settings, and click the button for the "one second" number of rounds. Increase it from there as you see fit, but just doing that even on a very slow machine increases your security significantly - I usually use millions to tens of millions of rounds, since a second or five doesn't matter compared to the speed savings of the auto-type feature.

Answer 2

Basic answer: don't do that!

Our current model at my employer is fundamentally flawed in my opinion

Your opinion is totally correct. Storing passwords in a file like this is A Very Bad Thing. Anti-weakpasswords is also correct: the first thing you should be doing in this situation is to implement a "proper" corporate access control infrastructure. For 99% of companies, this is MS Active Directory, although there are brave outliers who go with other options. But - to be brutally honest - it sounds like implementing AD properly will be a challenge for your company, so don't even think about the alternatives, which are harder.

The critical concept here is that the permission to do something should be associated with a role or group membership in the directory, and not with a specific set of user credentials. For example, you might have the situation where Lisa is the only person who should have the permission to mark an employee as "Terminated" in your HR system. But you've got to consider Lisa as transient: she might quit at any time. So you don't tie your authorization system to Lisa. Instead, you create a group called (say) Firers in your directory and add Lisa to that group. Then your applications just have to check whether the current user is in the Firers group, and not whether they are Lisa.

If you do this correctly, you won't have to bother with external password management systems like 1Pass or KeePass. These things have their place, certainly, but it is not in the internal access control system of an organization.