How can I convince my boss that storing third party passwords in plaintext is a bad idea?
Why is it a terrible idea?
By recording others' login credentials, the company is taking upon itself a liability. Since the company is now responsible for malice that could occur using those credentials, the company should take steps to minimize the risk. In addition, companies that interact with yours have to take upon the liability of trusting you, something that can harm business if an incident goes public (as mentioned by symcbean)
Storing passwords in plaintext (as you know) provides no protection against that risk.
What is a better solution?
As you mentioned in a comment, what you need is something like a password manager. In fact, what you want is a password manager.
Since there is a lot of room for error when it comes to cryptography, I suggest using an established password manager. You can find countless comparisons online, but in the end your choices include ones based around a GUI (like 1password, LastPass, keepass, etc) or one based an cli for automated access (like pass or via the LastPass cli)
Yes, you're doing something horribly wrong. That your employer appears to specialize in compliance makes it much, MUCH worse. The company's business is predicated on a reputation for excellence in compliance which you are actively flouting.
Unfortunately at all levels in an organization, convincing your superiors that what they are currently doing is a bad idea is difficult. If I were you, I'd suggest they consider how their clients would react if:
- they were told that you store their credentials in cleartext (presumably without any release/audit controls over usage)
- they read in the paper that another client had been compromised as a result of this practice
As to what a better approach would be...really you want the right approach, balancing confidentiality, integrity, availability and budget. There are commercial and open source products which would help with this, but it would need a lot more investigation and analysis than is appropriate for this forum.
You don't want to be storing user's passwords at all, not even in KeePass or something similar.
- The information is hidden by default but it can still be viewed easily
- Passwords are easily shared, losing accountability, i.e. how do you know it was the user and not someone else using their account?
- If a password is updated (e.g. a bad agent is discovered and you want to prevent further access), it must be updated everywhere else it's being used
These are some options, broken down by scenario:
If the systems you are using are your own and are actively maintained, you can ask for a user-spoofing feature. Each person with admin access logs in with their own admin account that is allowed to switch to any basic user's account without having to know their password. This way, you have better auditing. You can see that it wasn't the real user making the actions, but the specific admin user spoofing the user. This protects both you and the user since neither one can accuse the other of malice, unless it can be proved that the user had the admin password or the admin had the user's password and was using their account directly.
- You only have knowledge of your own password and can't discover any other user's password, even if threatened (a good hashing scheme takes hundreds of years to break per password, on average)
- You are only accountable for your own actions, not everyone else
- If a user's password is updated, it doesn't affect you because it doesn't change how you access their account
If the systems are external, i.e. third-party, you can attempt to negotiate the same kind of user-spoofing feature, keeping in mind that this might be a very low priority or not even a priority for some companies, i.e. might not ever happen, or might happen very slowly (think years).
If the systems are no longer maintained, you're out of luck. Your choices are to stop using them because of the risk, or keep storing passwords locally and accepting the risk.
Remember, it's not a question of if a breach will happen, but when a breach will happen.