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.