Should usernames and passwords to external systems be documented?

Question

This is basically an extension to my previous question. That time our internal discussions didn't end up anywhere and the whole issue was forgotten for the time being.

Now we've touched upon it again, this time with username/password credentials for external systems. So, a more generic/slightly different version of the same question:

When your system interfaces with multiple 3rd party external systems, there are some sort of endpoint configurations involved. Typically there will be a URL and either a username/password combo, an API key, or a client certificate. More often than not there will even be two sets of these - one for a testing/development environment, another for production.

So, after these have been communicated, what is the best practice what to do with them?

• My opinion is that they should be documented somewhere. If you want them to be secure, you can encrypt then somehow (KeePass, ZIP file with a password, whatever). But there should be a logical place where they should be kept against future need. Perhaps it can be in the project documentation. Perhaps there's a central storage for these. Whatever. Just - somewhere else where people can quickly find them when needed.
• My colleague's opinion is that they should NOT be documented anywhere. Well, OK, the test credentials can be documented, but the production credentials should only exist in a config file on the production server(s) and nowhere else. His reasoning is that nobody should need to access these credentials outside that server and storing them elsewhere compromises security. If the production server suffers a crash - that's what backups are for and those backups include the config files too. And if the whole system is so broken that even the backups are corrupted - then you have a bigger problem anyway.

Answer 1

Credentials come in different flavors, so you need different approaches.

User credentials should only be known to the user, who might employ password storage tools to protect against forgetting rarely used passwords. But they shouldn't be stored in any shared or unencrypted storage.

API keys (credentials used by applications to access services provided by other applications) should be stored on the machine consuming the API, and at least production credentials should also not be stored in shared storage (test configuration credentials may be handled less strictly).

For all kinds of credentials, there should be ways of creating new credentials for a user or an API consuming application, so loss of a credential should not be catastrophic. However, recreating credentials will in most cases require additional authentication and auditing.