How can I convince my boss that storing third party passwords in plaintext is a bad idea?

Question

Keeping things vague - I work at a company that handles compliance issues for our clients. Very often, this means we need to log onto their various accounts for various entities. We store their username and password, both to make it easier for them to remember and have access to, and for us to be able to log onto their account.

Ignoring the complete and total security nightmare of sharing logins for a minute, the username and passwords appear to be stored in plaintext. Hurray.

How can I convince my boss, and the higher ups, that A) This is a terrible idea, B) a better method/way of storing these

Answer 1

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)

Answer 2

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.

Answer 3

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:

1. 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

2. 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).

3. 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.

Answer 4

Yes, multiple things. Storing passwords in plaintext is obviously a bad idea. Encrypting them is better but typically passwords are not stored at all. A irreversable hash is stored instead.

But the larger issue here is that using a users password to fill in forms means that there's no way to know who did what with these passwords. Let's say one of the users in your customer base does something wrong, illegal even. They claim it must have been someone in your organization. Can you prove it wasn't? The users know you have access to the passwords, right?

And as mentioned in the other answers, it makes it much more likely that third parties can get these credentials and use them. If this happens, your organization is again potentially the target of the blame.

If I were you, I would explain the risks to whomever you can get to listen. If I understand correctly, these credentials are for third-party systems. Ideally, you would have accounts on those systems that are for your internal users. If you can't do that, you should try to have some sort of implementation that prevents people in your organization from being able to see the passwords and logs when they were accessing each system.

Answer 5

If you need to log into a foreign account of someone else, you need his username and password. There's no way around that. You can't hash or encrypt¹ them, you need the plain values.

Of course that's a nightmare, as the users need to disclose their credentials to you. They trust that you're not abusing them. Assuming that you are not intentionally abusing them (like selling them on the black market as a part of your business model), you need to prevent leakage. That includes data breaches in your infrastructure or database admins being able to access them. So the best practice here would to not store them at all. Your companies business is to help the user with filling out forms, not providing a password manager service. To "make it easier for [the users] to remember" their credentials is not your job.

One solution might be to write a browser extension for your users to install. They log into those foreign account themselves, on their machine, and your plugin does its work there. Your server does never even come into contact with the credentials. (Of course the user still needs to trust the extension not to spy on them).

If that's not an option and the work, including the login, needs to be done at your server, then you still should not store the user credentials. Just forward them to the foreign login service, and then only store the session token that is to be used with the API in your database for as long as you need it. If the database is breached, the attacker might be able to hijack the sessions (worse enough), but he does not get the plaintext password. Have the user provide the credentials again if your server needs to login multiple times.

_{1: Of course you should always encrypt any sensitive data when storing it anywhere, but ultimately the key to it has to reside somewhere on your server, to which a presumed attacker might gain access as well.}

Answer 6

Managers speak the language of business, not technology.

Make an estimate of the risk that your company faces with these practices, expressed in currency (USD, EUR, whatever is appropriate). There are various methods for doing that. A good approach is to estimate both a realistic and a worst-case scenario. Telling a manager that there is a 10% chance per year of a security incident that could cost the company up to 5 million in damage should get his ear.

In addition to potential damages from contract claims against you by your customer companies, you should also look at civil and criminal liabilities caused by gross negligence. A chance of going to jail is another thing that tends to get manager attention.

If your company has risk management in place, coordinate with the guys from there regarding methods and estimates, following corporate practices will make your approach more respectable.

---

The minimum precaution you need to take is to use a password manager or other system that a) stores the passwords encrypted and b) decrypts only the password needed, when needed.

Ideally you would move to a certificate-based method, but this does depend on your clients as well and is not entirely in your control.

You should also have a password handling policy in place that documents how passwords are handled and contains penalties for violating it. Egress filters could prevent an e-mail disaster.

Answer 7

Yes storing plaintext passwords is daft. We even had one staffer accidentally email all their "stored" passwords to an internal distribution list in a copy-paste accident. Fortunately no customers were on the list.

So we moved to using Teampass which works really well as a centralised database of password information.

It allows for groups with different levels of access too, and each user can have their own set of private passwords stored that no-one else can read.

Its a set up from an individual password manager where everyone keeps a copy of the passwords locally. So if the password for a service gets updated, everyone sees that update.

History is maintained too, so you can get the previous passwords for service X (maybe one host didn't get updated and you need to go back in time)

https://teampass.net/

Answer 8

Another angle except for the obvious (which you know already, as you show in the question - storing unencrypted passwords is bad):

Not sharing/giving out passwords is or should be one of the first bullet point in any security guideline. No sane bank, online service or whatever entity will ever ask for a password. This is ingrained in every user, for good reasons.

If I were your client, and your employer asked me for a password, I'd a) not give it to you and b) be running to my management pretty quickly. I would very much try to make sure that we were not your client anytime longer.

I do not even give my password to my own support guys (in the unlikely case that they need me to log in for them during a support session I will do so myself). I have been on the receiving end of security checks (for systems and/or applications) and never has any actual user account been passed to the security company. If they need to log in, they are getting their own temporary accounts. I had customers try to tell me their password, and I make pretty sure to interrupt them right away and have them type it in themselves.

TL;DR: Feel free to show your management this answer - I would be one customer lost to you.

Answer 9

The best answer is not to have or use your client's credentials at all. The act of asking for them from your client is a massive security no-no, and should be bringing up red flags for anybody at your clients who has any kind of security knowledge.

In fact, I'd say that your doing this is probably losing you business already among potential clients who have any kind of security policy. My own employer has a strict password policy and it would be likely be considered grounds for dismissal for me to share any of our passwords with you.

Another really important factor that no-one else has touched on is accountability. By sharing a password with you, the client has opened themselves up to potential problems if the account is ever misused. An rogue employee within the company may be the one to blame, but if the password has been shared it opens up an avenue of plausible deniability. They can cast suspicion onto you and make the investigation much more difficult.

But you need to log into this remote site as them to see what they're doing so that you can check their compliance, so how do you get around that without having their passwords?

There are a number of options here. They will all require more work than you're doing now, but you're going to have to accept that.

1. Find out whether the remote site offers account spoofing or multi-user accounts. If so, it should be possible for you to gain access to the same information without needing to use the same credentials. Either the site vendor or the client should set up an additional set of credentials just for you with access to view the client's data on the site. This login would be different from the client's main login and the password for it login would be yours alone, so there would be no issues of storage. Ideally this account for you would have reduced read-only permissions, to minimise any accountability risk to yourselves.

2. Discuss with the remote site vendor the possibility of them providing you with an offline copy of the relevant data. This may be in the form of a database dump or an API or a log file; whatever it is, it wouldn't involve you needing to actually log into the client's account; you could just request the latest copy of the data from the site and review it to find out what you want to know. This would obviously need to be agreed with the client, and if the site vendor doesn't have these facilities available, they may charge you for the work to create them, but it would give you full access to what you need, while remaining isolated from having to log into the actual site.

Answer 10

The FTC has gone after companies for such bad practices (see sections 3 & 4), litigating against them financially and publicly shaming them.

FTC also has the Safeguards Rule that gives some guidance (some high level technical but mostly procedural practices). Although it refers to financial organizations, their definition is pretty broad - in any case, a good starting point.