What is the safest way to store passwords in a company for the case when the CISO leaves?

Question

What is the best and safest way to store passwords in a company to ensure nothing is lost when the CISO leaves. I know this might be subjective and there isn't THE best way. But I'm curious about your approach.

The scenario is: The person responsible for IT has to manage a lot of passwords for servers and third-party services. It would be bad if these passwords are only known to the person in charge. The person can get sick, let go, etc. pp. So there needs to be a way for management to retrieve said passwords and make them accessible for other people - if needed. But they also need to be secure and only accessible in this case.

My approach would be to use a simple plain text file on an encrypted USB drive + one backup (also USB drive) in a secure (physical) location. Then provide management with the password for the drive. The person in charge can carry the drive around like a key. If stolen, it is useless. If lost, there is a backup. If person isn't available anymore, management can access it.

Thoughts?

Answer 1

What's the best way to store passwords?

This is a very broad subject that encompasses many different areas of IT. It also has the tendency to be opinion-based. However, there are some very important things we can know, and then use to make an informed decision.

Also, there are many different ways to handle passwords. What size company? Small? Medium? Large? Colossal? In my opinion, you can't just ask for the best way to store passwords, nor store them all in the same place in all cases. You have to know why people need passwords, and when they need them.

You also need to know what will happen if you have to change the passwords (due to a breach, etc). And after that, you have to know the impact of changing the passwords. Will it break your applications? If so, how quickly can the developers update their code? Does it violate the CIA triad? CIA Triad = Confidentiality, Integrity, Availability.

Your passwords should be hashed with a proper algorithm, and not stored in plain-text, but at the same time, many different roles require a lot of plain-text passwords. There's a difference between a plain-text print-out, and storing unhashed passwords in the database. Do not mix these concepts up.

Information Security is all about risk management. You cannot 100% account for every scenario, but you can do your due diligence to dramatically minimize risk.

The scenario is: The person responsible for IT has to manage a lot of passwords for servers and third-party services. It would be bad if these passwords are only known to the person in charge. The person can get sick, let go, etc. pp. So there needs to be a way for management to retrieve said passwords and make them accessible for other people - if needed. But they also need to be secure and only accessible in this case.

---

What kind of polices should be in place?

1. Upper Management should be able to request password changes for all accounts, even if they don't know the passwords, so that password changes aren't a problem. There should also be an audit trail for this to help avoid framing someone. For Windows, Active Directory can do this, and is very powerful.
2. All important usernames and passwords should be split up and only given to those with the correct role(s).

---

Development teams frequently need important passwords

If you have a development team, chances are you'll have lots of different passwords. Not just passwords, but usernames as well. For example, you may have broken up your your development, testing, and production environments. If you haven't done that, you have terrible IT practices.

No one except trusted DBAs should have root access to the production database. And only the trusted System Administrators should have access to the production servers.

Storing passwords in plain text can be a bad idea. In the case of customer data, it's definitely a terrible idea. A good use-case example would be for development teams. How is the development team going to upgrade the database? How are they going to test their changes?

The developers can't if they don't have access. If they have to keep requesting passwords to test their changes, productivity falls, ideas are lost, and your company can't remain competitive.

You need separation of concerns. In order to change the production database, you should have the appropriate permissions and instructions. Your run-of-the-mill developer should not have access to either the production database or server.

However, your developer definitely needs access to the development and testing environments. In this case, your developers should be given a print-out of database usernames and passwords that are relevant to them. As a further stop-gap, you should have enterprise profiles that only allow access to those accounts if they have permission, so even if they get the password, they can't connect without appropriate permission.

Within a medium-to-large company, being able to properly develop without too many hindrances is critical. Being held back by red tape is extremely detrimental to the development process.

---

Get off your soap box and let's get back to password storage!

My approach would be to use a simple plain text file on an encrypted USB drive + one backup (also USB drive) in a secure (physical) location. Then provide management with the password for the drive. The person in charge can carry the drive around like a key. If stolen, it is useless. If lost, there is a backup. If person isn't available anymore, management can access it.

This is the way many companies do it. However, I would take it a step further due to tinfoil hattery:

1. Create an application where you are able to change passwords.
2. Plug 4 USB devices into the computer.
3. Application writes passwords to multiple flash drives for redundancy. Can update just as easily, and role-appropriate print-outs can be given to the correct users.
4. Ensure that all passwords can be changed by a master account. Ideally, you'd want more than one.
5. You'd also need paper documentation in a locked room that few have access to.

Answer 2

I'll go for the secure password manager application. However, my Approach may also apply the split knowledge for the master vault password (Should be stakeholders or senior management to hold this). Which means one party couldn't be able to delete anything without tracking. The permission level will be shown below

---

master <== can do eveything

---

Administrator <== almost master but can't do limited function and/or can't change master profile

---

Normal Users

---

In this approach, the backup process will become crucial part as the administrator still able to destroy the vault password depends on your access control.

Answer 3

I've been using keepass for years and I'm very happy with it. I have my password database synchronised between my devices using dropbox, and the database is encrypted with a password + keyfile (which I manually copy to each required device). This means that even if someone was able to compromise my dropbox, and gain access to the database, it would be useless to them, as they won't have the keyfile or password to open it. Potentially you could use a similar approach in a multi-user system. The drawback with this approach is that if passwords are maliciously removed or changed, the changed file will be synched to the other devices. A scheduled backup of the password database file may mitigate this risk.

Answer 4

Thankfully the world has evolved away from the old break-the-glass style of storing things on a USB key, and that evolution is (free and open source!) Vault. It has clear and obvious mechanisms for key rotation, uses ephemeral secrets when possible, and has full audit logging, and ultimately the very magical possibility of instantly revoking any credential a user has ever accessed.

It also provides for high availability through systems like Consul, etcd, and ZooKeeper.

Finally, as is used in vault and a great solution for encrypting anything that you want to require multiple people to work together to decrypt, be aware of Shamir's Secret Sharing which is available via the gfshare command and is great for securing decryption keys such that multiple people must work together to decrypt data.

Answer 5

I very strongly recommend you evaluate SecretServer. It is on-prem web-based, has excellent logging and auditing, supports devs, ops, security, et cetera.

You can script against its API to check out "secrets" for operations that need them, as they need them, then when the "secrets" are checked back in, the password for each is reset automatically.

Answer 6

I've been researching into something very similar, and from the few options that we had I came to the conclusion of using something like KeePassX. It is open source and is pretty much cross-platform version of KeePass. It stores the passwords in encrypted database and can be accessed using a key and password. I was thinking to store the database on one of our machines and would allow users in our area to access it and only allow them to access it off-site by using VPN. It also has a auditing feature to keep track of people that modify the database.