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

  • 20
    Why would you need to log into the user's account? What are you trying to accomplish by logging into the user's account? – saghaulor Feb 23 '18 at 17:29
  • 3
    Doing the prep work/form fill out for them. I've been fighting this as well.... – Selkie Feb 23 '18 at 17:33
  • 48
    Our system has an audited impersonation system so you can log in as someone else while it being clear who actually made the action even if it was in someonew else's name (we use this principly to see bugs that require exactly their data to appear). Could this work for your company? – Richard Tingle Feb 23 '18 at 22:27
  • 45
    There's surely something ironic about a company that provides compliance services dropping the ball so blatantly. – Lightness Races in Orbit Feb 24 '18 at 14:59
  • 20
    "Are we doing something horribly wrong security-wise?" Yes. Without reading the question body, just on general principle, if we've learned anything from the last 20 years or so, the answer to the question posed in the title is almost certainly yes, for any value of "we" that is an organization in the computer industry. :P – Mason Wheeler Feb 25 '18 at 4:09

10 Answers 10


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)

  • 3
    I'd recommend either 1password (1password.com) or LastPass (lastpass.com). Both have a GUI and a cli for automated access. – user196499 Feb 23 '18 at 19:44
  • 2
    I'd break the options down into web based GUI, local file based GUI. Are the CLIs file or web based? Or do they also come in both varieties? – jpmc26 Feb 23 '18 at 21:58
  • 3
    @Selkie I'd put in a plug for Thycotic Secret Server. There is (or was) a free version that I've used for years across a couple different employers, and the current employer recently shelled out to upgrade to a paid license. Scales well, on-prem, easy to use and administer. – HopelessN00b Feb 23 '18 at 22:07
  • 4
    I wouldn't recommend a password manager for such uses. If the computer is compromised, so are the passwords - it doesn't matter which manager is used when a targeted attack occurs (which seems like the most likely case in this situation). – user169249 Feb 25 '18 at 21:58
  • 5
    @Naim - what else would you recommend for such uses? I would say that this use is a very poor practice and they shouldn't be doing it at all (using customer passwords to log on as them), but if they have to do it this way, if not a password manager, then what? Hand-written passwords? If a computer is compromised then any password used on that computer is compromised. – Johnny Feb 26 '18 at 2:33

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.

  • Fair enough - I was wondering if there was something like "Yeah, encrypt the passwords using X, then have the ability to move the passwords to the clipboard without seeing them", kind of like a password manager. – Selkie Feb 23 '18 at 17:12
  • Well, but could you line out a possible better approach? – Arminius Feb 23 '18 at 18:41
  • If you are using SQL server for data storage, you could use column encryption feature of the DB. I can't remember from what version the data encryption was added to SQL server, but that might be what you are looking for. – Sparrow Feb 23 '18 at 21:36
  • 3
    Btw, we have implemented a solution for these cases. A user can 'delegate' his/her account role to another user for a specific date range. When you need to see what user is seeing, you ask user to delegate his account to you. You login with your own credentials, and system lets you to choose to login as yourself or the other user. If you select the other user, your session will have all the permissions as the other user except a few pages. Using this feature, you don't need access to other users passwords, so you can actually properly hash the passwords and move away from plain text passwords – Sparrow Feb 23 '18 at 21:41
  • "using an SQL server" or any other database management system does not solve the problem of access control and auditing. Throwing encryption into the mix adds complications. – symcbean Feb 24 '18 at 17:07

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.

  • 2
    Your last sentence should really be the first one. – Wayne Werner Feb 26 '18 at 17:25

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.


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

  • 1
    I agree that you cannot hash them, but I see no reason why you can't encrypt them. – Jon Bentley Feb 24 '18 at 17:10
  • @JonBentley I meant like "encrypt so that you cannot decrypt it yourself". If you keep encrypted data and the decryption key close together, it doesn't help a lot. See also the footnote. How can I phrase this better? – Bergi Feb 24 '18 at 17:16
  • How isn't there a way around that? There can be a system that circumvents the login process entirely by using multiple security measures like: (i) a custom url for login, (ii) confirmation email sent to trusted email account(s), (iii) need for a master password. This way you can have support members getting into the clients' accounts for assistance. – hytromo Feb 24 '18 at 18:34
  • @hakermania: Can you elaborate on your reference to a ‘‘master password’’? ISTM that storing a master password is just as bad as storing a bunch of individual passwords, and modifying a system to accept a master password makes the system less secure. – Scott Feb 24 '18 at 20:05
  • 1
    @hakermania I understand that the OPs company needs access to their clients' accounts on foreign systems. Assuming those foreign systems don't support access by third parties, the user credentials need to be used in the normal login. (Of course when there is an API for third party access, that should be used). I don't understand what you mean by "custom url + trusted email + master password". – Bergi Feb 25 '18 at 7:39

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.

  • It is easy to explain that there is a risk, that consequences could be serious, and that this risk could be easily mitigated. But giving a precise evaluation (10% per year) is much more difficult. The answer could be: we have been doing that for 5 years and still no problem, so your evaluation does not make sense. – Serge Ballesta Feb 26 '18 at 12:58
  • 1
    An estimate of the probability is an absolute necessity to estimate the risk. Of course it is an estimate, but you should be able to at least give a range. If it helps you can inverse it and state not % per year but MTBF - every how many years do you expect this to happen? – Tom Feb 26 '18 at 19:32
  • 1
    Second, the "nothing bad happened so far" isa common fallacy. It's the exact thought that people had in Tchernobyl the day before it exploded. If something is expected to happen every 5 years, and you had 5 years without it, it is time to get nervous because you are overdue. The proper answer, however, is that you can use this data to revise your estimate. – Tom Feb 26 '18 at 19:34
  • If there is a breach, OP's boss will in this order (1) not know about it, (2) minimize its impact, (3) buy credit monitoring, (4) declare bankruptcy. There is a 90% chance that it will not get past stage 1. It is extremely unlikely to go past stage 2. In the worst case, stage 4, the principals will not be materially affected. – emory Feb 27 '18 at 12:24
  • I think if you want to make a business case, then you would have to give an estimate of the size market that would simply refuse to give you their credentials (eg., me). OP's company is simply throwing away the segment of the market that are not security morons. This, however, would require completely reworking the process. – emory Feb 27 '18 at 12:27

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)



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.

  • 1
    There's nothing wrong with writing down passwords if you keep them in a safe place. – Bergi Feb 25 '18 at 23:05
  • @Bergi, well, OP said they do it in an unsafe, unencrypted place. But I've removed two words to make it perfectly clear that my answer is not about that at all, but about the "identity sharing" aspect. And I'm firmly sticking with the proposal that it is not OK to give out passwords who are linked to real identies, no matter where the PWs are then stored. – AnoE Feb 25 '18 at 23:24

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.

  • "accountability" is covered by the top-voted answer – schroeder Feb 26 '18 at 14:05
  • "lost customers" is also covered by another answer – schroeder Feb 26 '18 at 14:07
  • Your #1 suggestion is not common, and given that there appear to be many entities, it is not a scalable solution. Your #2 suggestion might be worse than knowing the password, depending on the content of the data. – schroeder Feb 26 '18 at 14:11
  • @schroeder - #2 would only be worse if all parties involved were incompetent. It should provide at most exactly the same data as is visible by logging in; nothing more and preferably less, to only cover what is actually needed. If the vendor sends you a dump of their entire DB, then yes, that's a bigger problem, but one would hope that the vendor would know better than to do that and the OP's company would know better than to ask for it. – Simba Feb 26 '18 at 15:21
  • Also re "there appear to be many entities"... actually, I read the OP's comment to mean that there was only one third party entity involved; he said "It's a webpage we go to and log into". If it is singular as I read it, then these solutions should be perfectly workable. Even if it's a small number of sites, it should be doable. Yes it won't scale well if it's large numbers of sites and different ones for each client, but that's not how it read it. – Simba Feb 26 '18 at 15:25

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.

  • your first link does not apply to the OP's situation if the passwords are stored and transmitted securely – schroeder Feb 26 '18 at 14:08
  • your second link also does not appear to apply – schroeder Feb 26 '18 at 14:12
  • Updated first link so it encompasses broader issue of secure storage (i.e. not plaintext). Second link refers to storage of sensitive information (which we can take to include account information) that should be safeguarded. cc @schroeder – HTLee Feb 26 '18 at 14:26
  • I read those sections, and they still do not apply. You are stretching to try and make something fit. I can satisfy those requirements by using full disk encryption. Yes, the OP is in a poor situation, these links are not useful as prompts to better action, though. – schroeder Feb 26 '18 at 14:31
  • 2
    Besides schroeder's points, this is only applicable if the OP is in the US. Something I don't think that we know. – Neil Smithline Feb 26 '18 at 14:59

protected by Rory Alsop Feb 26 '18 at 16:57

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.