How to safely save passwords for a future administrator?

Question

I am the volunteer IT administrator for a local non-profit organization. The organization has a few systems - specifically security cameras, network hardware, and telephones - that have local administrator accounts to manage them. Right now, I am the only person working for the organization with any amount of technical knowledge about these things. As part of our disaster recovery plans, I am writing a complete manual for administration of everything in the building.

The problem is what to do about passwords. No one else in the organization wants to be responsible for having the administrator passwords to everything (and honestly I don't trust them anyway), but reducing the bus factor necessitates that a password be available somewhere for some other person to manage these devices in the future.

My first thought was to use something like LastPass's "Emergency Access" feature that allows another user to request access to an account, except that I have no idea who that future user might be to give them permission and I have no confidence in this feature working properly anyway (since my wife and I tested it with our accounts and it didn't work).

My current thought (loosely inspired by the opening scene of WarGames) is to generate secure passwords for the accounts and make scratch-off cards with the passwords on them. These cards would be kept in a sealed envelope in the manual binder. Access to the passwords then requires opening the envelope and scratching the cards.

I am not worried about someone going through the effort to steam open the envelope, scratch the cards, copy the passwords, then re-cover the cards in scratch-off material, and perfectly re-seal the (signed edge) envelope. Physical access control will prevent outsiders from doing that, and we are confident that all of our insiders don't want the passwords and wouldn't know what to do with these passwords even if they had them.

I know that this plan is still vulnerable to anyone with physical access gaining admin rights, but I can't think of any better options.

Is this a good plan? Are there better alternatives? Or am I overthinking it?

Answer 1

Offline password manager

I would use an offline password manager (for example, KeepassXC as an open source option) for the whole list of credentials that may need to be accessed by someone else.

The encrypted file containing the passwords can be given to any relevant persons and management beforehand, or it may be stored in some network location that's accessible also to some of your colleagues. But the passphrase (and possibly 2FA token) to access that file can be physically put in an envelope in a safe to be given to the appropriate person if/when needed.

This also means that you can continuously keep that credential list up to date without touching that 'envelope in a safe'.

Answer 2

I would do something like this:

1. Create an encrypted text file with the passwords that has enough copies to survive the level of disaster you're protecting it from.
2. Make a plain text printout of the private key used.
3. Store this printout in a secure place (the bank's lockers, at an attorney, in a fire resistant safe) but make sure its location physically differs from the encrypted text.
4. Make a fool proof guide on how to use the key to decrypt the text file. Make sure to add enough details so the software used can be identified years later.
5. ???
6. Profit.

If you use such a key to co-encrypt your up-to-date password file it would mean that with some steps a person in the know can gain access to the accounts.

If you prefer a more service based solution you could convince your fellows to use a password manager for it. Most of those can be setup so that you need 2/3 keys (or however many you need) to unlock the database.

In a pinch even a service like Last Pass could be used, but those require payments for their upkeep and would just shift the problem without actually solving it in my opinion.

Answer 3

There's a lot of good ideas here to pick from. However, all of them should come after a key step: develop a threat model.

What sort of adversary are you protecting against? This will dictate how well you need to protect your copies of the password. What sort of interruptions are acceptable for your organization, and how bad can a lack of these passwords upset the organization.

For many organizations, a file where you write the passwords down is a sufficient match to the threat model. For others, you may need a offline password manager. If you're in the bitcoin vault business, with billions of dollars at stake, you probably want something stronger. There is no one solution for everything.

When I was in college, one of the students who ran our Kerberos server left without handing it off. We had a hacking party to try to break into it, but no avail. We ended up re-imaging the computer.

What was the cost? It turned out not to be very high. We did not have anyone who was using Kerberos in an "essential" way. It was really just convenient for us to have it. Nobody really tried to keep our data safe. So when the server went down, we found ways of accessing our data without Kerberos.

Answer 4

If physical security is not a concern for you, given all of your constraints then a time-delay combination lock might be a better option than scratch-off cards. Install one in a fixed visible location and set it so many people become aware before it opens.

Answer 5

You could generate n of m key shares that need to be combined in order to recover the original secret using Shamir's Secret Sharing algorithm. Then you distribute the parts amongst different people. You can decide whether you keep the remaining part or even create more parts than necessary in order to reassemble the original secret.

E.g. using the following implementations: Windows: https://github.com/aseidlitz/ssss-win32 Linux: https://linux.die.net/man/1/ssss

Example

The following example shows how a password can be split without revealing it. It should be split immediately after creation e.g. printed. The complete list then needs to be discarded. One could also pipe it into a small script that reveals only one line and then clears the display.

$ sudo apt-get update && sudo apt-get install -y ssss
$ head -c 16 /dev/urandom | base64 | ssss-split -t 3 -n 6
Generating shares using a (3,6) scheme with dynamic security level.
Enter the secret, at most 128 ASCII characters: Using a 192 bit security level.
1-045e897dc1d944691ca6202556532883c0043ae24883cdca
2-9fbd388ba9d314cac6eaf5f61f9a7c8d2fb69d3a0cd2e43f
3-642f2727d6e24b5c30730a57afbdf0ad062314beb3525ac0
4-62798e6e35f8c5f6b40edfa7732e154431ef1a8913e3f5b9
5-99eb91c24ac99a6042972006c3099964187a930dac634b54
6-0208203422c3cac398dbf5d58ac0cd6af7c834d5e8326285

Answer 6

I'd just print them out on a medium that is going to survive the device itself (so laser printer instead of inkjet), and ask the organization's administrator to put them in the organization's safe, inside an envelope that lists the devices' type and asset tags (so a future administrator can determine when it is safe to throw away).

Realistically, none of these devices will be in operation twenty years from now, and even ten is probably going to stretch it, while the organization most likely has record-keeping duties for ten years, so it would be a matter of adding an envelope to that pile. Give it a different color.

Answer 7

Your intention here is to make your replacement grateful to you for your foresight/planning, and not curse your name for years to come.

Upshot - if you contract Red Bus Syndrome, whatever process has to be accessible and simple for non-technical people to find a technical person/team to replace you.

Do consider the risk case - its a non-profit. Doubtless there will be personal information of users but there's not going to be any credit cards or state secrets to protect from malicious action.

---

20 years ago I worked in a high school as network administrator. There were plenty of disparate credentials, from wireless APs to printers to Active Directory stuff, and bios passwords through to web-based software services and site serial numbers.

All of this was in an encrypted text file which was stored on a 32 MB USB1 pen drive with write protect switch, that hung on the wall behind my 17" CRT. Any password change was edited into that file when it happened. Every school holidays, which was about ~4 months, I'd print the file onto archive paper, fold/envelope/seal it, and the finance lady would store it inside her fireproof safe. Then I'd dispose of the obsolete copy in the coal-fired boiler's firebox.

Each printout had a "date printed" field on it to help avoid mix-ups.

Answer 8

The scratch-off card idea is interesting, but those can be tricky to make. Plus there's always people like me that scratch too hard and tear the paper. Not to mention water damage...

Instead, you can save the passwords on a slim flash drive (or even a few scraps of paper) and put them inside a good old-fashioned piggy bank (grab one at a thrift store for a few bucks). You have the same "break glass in case of new administrator" effect but easier to implement. And it looks better out on a shelf.

Updating passwords is difficult once they're sealed away, though. If you want something easier to update, try this. Record all your passwords in a normal text file, then encrypt the file. Store the encrypted version of the file in several easy-to find places (you can even keep a printed copy of the hex dump of the file in your desk drawer). Provide a copy of the decryption key and instructions to someone like your organization's lawyer or store it in your deposit box at the bank (if you have one). That will let you update your password file whenever you need to, and the static copy of the key is still valid. For the best chance at disaster recovery, encrypt using a one-time pad. These are much easier to decrypt by hand, in the event that your successor doesn't have the software that you used. Your file isn't going to be very long, so you don't have to worry about a gigantic pad.

Answer 9

I think what I'm going to put its the combination of different elements from the answers, There is a service called Hashicorp Vault. This is a secret manager where the vault can be closed using the Shamir algorithm so you can create secrets and the access to them through devices, sso or username/password in the platform, but once you lock the vault this can only be unlocked with a set of passwords you can share with the main involved ones in the business. Vault

Answer 10

In an ideal world:

• Your fellow organization members, in particular the board members and officers, would have user accounts with strong passwords (NIST Special Publication 800-63B Revision 4).
• Your systems would all have a centralized method of updating passwords for all devices.
• Board members would hold permission to grant or suspend 'Administrative' privileges upon a vote (or an otherwise agreed upon process described in the bylaws) designating the relevant organization member.

The way you describe your organization, it sounds as if your peers may not have unique credentials to access the relevant systems. Because I've found security cameras tend to be antiquated and lack integration with other authentication systems, I'd not be surprised if a centralized method of credential verification and revocation is not possible.

If this is the case, I'd say that it's back to pen and paper. The board members should have a responsible means of storing privileged credentials, whether it be a physical vault, a password manager on their phone, etc.. and these credentials should be communicated to the relevant organization members. The process of regular updating of passwords may be a manual one, but should be done regularly. If your organizational hierarchy has a director rather than a board, then it is the director's responsibility to hold these credentials, plan for the transfer of these credentials to their successor, and share them with the relevant organizational members. Ultimately you as the system administrator should not be the sole holder of system credentials. If you are, then your organization's leaders are making a mistake. You ought to try and outline and express this issue, but ultimately I would say the decision of how to manage privileged credentials should not be a system administrator's in the first place.

Answer 11

If you have a little bit of software writing capabilities (and your colleagues don't) then you could encrypt the list of passwords with a password that you give to your backup folks. But then to access the encrypted data they have to start a process that sends your admin account a message/email as a notification, and then after some amount of time (i.e., 24h) gives them access to the encrypted password file.

If you were still with the organization and this access was undesirable, you could kill the upcoming access to the file.

Certainly this could be circumvented with some technological knowledge but:

1. It would require technological knowledge, which the people you are trusting with the backup passwords don't have.
2. It requires the password either way, so you don't have to worry about an attack from someone on the outside.

The main failure to the system is if one of your trusted people ends up letting the password get out into the wild, and then an untrusted person gets the password, has technical knowledge to stop your warning system and has enough access to the computer that is running the warning system (such as to unplug it's internet, though there are ways your software could require that).

You could also combine this with a distributed shared key as mentioned elsewhere which would mitigate the risk further - though I'd have more than one distributed shared key if you do that, otherwise everything is lost if one key is lost.

So it's not foolproof or perfectly secure, but what you want is something that allows for a compromise of security to begin with.

Answer 12

In my opinion you're not overthinking it. Rightful access during an emergency is as much part of the information security puzzle as other considerations. I'm in a similar situation and part of our solution involves the use of KeepassXC with a second factor, which is already mentioned by others, but for which I will expand on in this answer. KPXC can be used on numerous platforms. I also draw to your attention two additional utilities that make this a good choice:

• KeepassDX, which gives you access to your kdbx file on an Android device ^1,
• and keepassxc-cli, which grants automated exports from the command-line.

Exporting the contents of a kdbx from the cmdline

Firstly, you don't actually need to automate the export. You can periodically produce a plain-text export from the secrets database using the Database > Export > CSV menu option, and place this file somewhere secure. You could theoretically place this into an encrypted container, eg LUKS or Veracrypt. Of course, unlocking, mounting, writing to, and un-mounting such a container could also be automated using a similar auto-type technique, described subsequently.

To export the kdbx entries in semi-structured form (xml) from the command line, using keepassxc-cli:

keepassxc.cli export --key-file ~/Desktop/.N.key ~/N.kdbx

Now, in our case, the export is piped to openssl, which in turn encrypts using a complex password that likely can't be remembered, but can be transcribed relatively easily ^3 on a phone's soft-keyboard.

#!/bin/bash
_KFILE="Nkdbx.$(date +%Y%m%j%H)" && 
_KPXRT=$(keepassxc.cli export --key-file ~/Desktop/.N.key ~/N.kdbx) && 
echo -n "$_KPXRT" | 
openssl enc -aes-256-cbc -pbkdf2 -iter 3000000 -out "$_KFILE" && 
unset _KPXRT && chmod 0400 "$_KFILE"

To decrypt the export backup in the future, but limit the output on the cli using grep (ie. once you decrypt and print to the cli, you must then change those account passwords to ensure the credentials can't be found in some scroll-back buffer or log):

openssl enc -d -aes-256-cbc -pbkdf2 -iter 3000000 -in Nkdbx.2020xxx | grep -9 'ACCOUNT_CLUE'

... where ACCOUNT_CLUE is some search string for the account details you're looking for

Configuring a new KPXC entry to auto-type an encrypted export

In KPXC, you can create entries that are configured to auto-type into a terminal window, which unlocks a particular KDBX file, and dumps the content into a plain-text file using keepassxc-cli ^2.

The use of these auto-type entries is done by bringing up a terminal window, then switching back to your KPXC window, then selecting the appropriate entry, right-clicking, and selecting Perform Auto-Type. KPXC will now switch back to the terminal window and execute the command on your behalf.

You configure auto-type through the Auto-Type settings in password Edit entry, and you manage the commands in the Edit entry > Advanced > Additional attributes section.

First, we'll add an attribute called CLI_PWD and tick PROTECT. Now, click Reveal and then click in the edit box. Finally, type the password for this kdbx into this, then Apply.

We'll add an attribute called CLI_EXPORT with the value described previously, but now on a single line:

_KFILE="Nkdbx.$(date +%Y%m%j%H)" && _KPXRT=$(keepassxc.cli export --key-file ~/Desktop/.N.key ~/N.kdbx) && echo -n "$_KPXRT" | openssl enc -aes-256-cbc -pbkdf2 -iter 3000000 -out "$_KFILE" && unset _KPXRT && chmod 0400 "$_KFILE"

Next switch to the Auto-Type section for the entry and choose use custom auto-type sequence:

{S:CLI_EXPORT}{ENTER}{DELAY 400}{S:CLI_PWD}{ENTER}{DELAY 4000}{PASSWORD}{ENTER}{DELAY 250}{PASSWORD}{ENTER}

This bit can be tricky, and will depend on your machine as well as the parameters you chose for your kdbx security ^1. On my machine, {DELAY 400} is enough time for keepassxc-cli to load and parse the kdbx file, and {DELAY 4000} is enough time for the kdbx file to be unlocked. What will happen if these auto-types occur too early is that the secrets will show up in the command line - everything else works as expected, however, because it is still read as stdin.

Doco is here: https://keepassxc.org/docs/KeePassXC_UserGuide.html#_configure_auto_type_sequences

I should note that this is a manually triggered process that results in a separate exported file that doesn't rely on KeepassXC, rather, only openssl. We still bak the kdbx file through a separate automated process.

The choice of openssl to secure the export is debatable, because it doesn't provide for integrity of the encrypted file at this time. I vaguely remember reading somewhere that it wasn't possible to modify openssl to use AEAD on the command line, because the output format couldn't be modified to include the authentication tag, and still maintain backwards compatibility. If this is important to you (ie. if your encrypted export is readily accessible by potential adversaries), then another tool such as age, see https://github.com/FiloSottile/age could be a better choice.

Notes

^1 Some sensible, long-term settings for your database security would be:

• use a password and a keyfile
• use KDBX version 4, KDF Argon2 - Argon2 is a password-based key derivation function (PBKDF) that has tunable 'hardness factors', designed to slow down the dictionary-based attacks to determine the password that generates your master encryption key
• if you intend using this on Android devices with ARM:
  • consider ChaCha20, viz. https://crypto.stackexchange.com/q/34455
  • RAM 32MB (33554432 bytes)
  • parallelism 4-8 (check your chip)
  • rounds 11
• if you'll only ever access using a desktop/ server, with AES cooked into the cpu core:
  • AES or ChaCha20
  • RAM 1024MB
  • parallelism 8
  • rounds 15
• set yourself a task to review these numbers each year - you can change them after the fact, as processors get more powerful

^2 This works in KPXC, but to be sure I would un-select 'automatically save after every change' in the settings, so the kdbx file doesn't get modified when you perform 'auto-type' - this may not suit your needs, the downside being that your changes aren't automatically saved: you now need to manually save the database, or wait 'til it locks. I've looked through the source code a while ago and couldn't see anything that may lead to corruption, however, to be sure you should also un-select automatically reload the database when modified externally and select safely save database files.

^3 A starting choice would be 14 lower-case alpha and numeric characters, chosen at random and each possibility being equally likely, which you then extend by distributing five additional punctuation characters throughout the password, chosen from the range that can be typed on a soft-keyboard on a phone without the use of the SHIFT-modifier. I calculate the strength for this to be over 80 bits of CS-entropy, ie. log-base2 (36^14 x 5^5).

You must, of course, write this down somewhere once the password manager picks it. To decrypt on any Android phone, you can instal Termux and then add the openssl utility pkg search openssl and pkg install openssl-tool

Argon2

Argon2 inputs and outputs - https://tools.ietf.org/id/draft-irtf-cfrg-argon2-05.html#rfc.section.3

Message string P, which is a password for password hashing applications. MUST have length from 0 to 2^(32) - 1 bytes.

Nonce S, which is a salt for password hashing applications. MUST have length not greater than 2^(32)-1 bytes. 16 bytes is RECOMMENDED for password hashing. Salt SHOULD be unique for each password.

Degree of parallelism p determines how many independent (but synchronizing) computational chains (lanes) can be run. It MUST be an integer value from 1 to 2^(24)-1.

Tag length T MUST be an integer number of bytes from 4 to 2^(32)-1.

Memory size m MUST be an integer number of kibibytes from 8*p to 2^(32)-1. The actual number of blocks is m', which is m rounded down to the nearest multiple of 4*p.

Number of iterations t (used to tune the running time independently of the memory size) MUST be an integer number from 1 to 2^(32)-1.

Answer 13

You put your passwords in a vault. Congratulations! The real work has just begun. As with any backup, how do you know it works, and how do you know its complete? Were they transcribed correctly? What about answers to security questions? 2FA codes? Private keys (SSH, GPG, SSL, Digital IDs)?

And how do you keep them up to date?

The best answer I've found is to store what you use. And if your office is already using a shared password manager this becomes much easier. I use 1Password shared vaults for this purpose, but it can be any password manager which provides this functionality.

While you're thinking about using this for Big Disasters, it will likely be used in mundane situations, like when you're on vacation. Shared vaults let you ensure at least two people have access to each shared vault to increase your bus number in more mundane circumstances. No safe required.

You can also store an Emergency Kit (test that it works) in a secure location (for example, a safe only accessible by the organization's officers) for access. You'd also make an offline copy of the vault in case the network or 1Password service is unavailable. This snapshot can be kept up to date by grabbing a fresh offline copy as part of your normal backup procedure. Because it's encrypted, the offline backup can be accessible to more people to do the backup. Only the Emergency Kit needs to be truly kept secure.

This can also include answers to security questions, 2FA codes, private keys (SSH, GPG, SSL), and any secure information a future administrator needs.

Then you'd use the same password manager for your organization solving multiple office security problems. This makes it easy to keep the emergency password vault up to date, and you know they're correct and complete because this is the same password vault everyone is using.

Answer 14

The organization has a few systems - specifically security cameras, network hardware, and telephones - that have local administrator accounts to manage them.

I apologize if my question is naive: What would you do if one of these had a major software or hardware failure necessitating a reinstallation of the operating system?

My hope was that in an ideal world, you are also documenting how the software setup works, i.e. steps for a "fresh install". This would of course include setting the new passwords. And again ideally, the process would hopefully be clear and well-documented enough that the new administrator could just follow it for each device -- this also gives them a chance to get familiar with the devices anyway.

In this case, you don't need to leave behind passwords; the new administrator will reinstall things and set new passwords.

---

P.S. Maybe this isn't possible because the devices run some proprietary software that you can't reinstall (and hopefully never crashes nor needs replacement parts?). Also, this solution doesn't take care of the scenario that you suddenly leave and the organization needs short-term access until a new person starts. It wasn't clear if that's part of your requirements.