2

How should clients' passwords be managed? By "clients" of course I mean people who you provide a service to, people who need you to work on their stuff (their websites, their servers, their emails, or other services they use in general).

Every time I read about password managers, I always see examples and arguments that only involve personal passwords, not passwords managed on behalf of other people. And I'm not sure if using a password manager for this purpose is a good idea, or if there are better standard practices. What if I'm managing passwords for a hundred clients, and I get hacked? Should I tell each client "Sorry, I got hacked, now we need to change your email password?" A better option would be to avoid storing other people's passwords, but that would mean you'd have to keep asking the client to provide their password every time you need to access their services (which might be often or rarely, depending on the kind of support). Lots of clients might not even know (or regularly forget or lose) some of their passwords, for example those needed to manage their domains, or their web panels, etc., all stuff they never touch but it's still technically "their stuff" anyway.

So I'm wondering if there are some better methods, policies, or practices to deal with these scenarios, or if the usual password manager with "all eggs in one basket" (my eggs and everybody's eggs) is still the only solution.

  • 1
    Is this for automated access, or manual fingers-on-the-keyboard logins? – nbering Jan 28 at 14:26
  • @nbering, no, not automated. I'm talking about manual logins, for typical support (check this, fix that, upload a file, etc.) – reed Jan 28 at 16:11
  • Password manager advice seems reasonable then. If there was automation I was going to suggest something like Hashicorp Vault, but that seems a bit heavy if there’s a person in the loop. – nbering Jan 28 at 16:13
  • So to clarify, the password you get comes from a client saying to you "Here is the password you can use to log in as me"? And the password is either for the client's machine or a client's account with a third party? – Future Security Jan 28 at 21:13
  • @FutureSecurity, yes. Like "here's the password for managing the DNS so you can add a record", or "here's the web panel password so you can fix my website", etc. In other words: access to stuff that is not mine anyway, even if I had a separate account from the client. – reed Jan 31 at 22:19
6

In an ideal world, you should never use other peoples passwords, and therefore you should have no need to store them. If you need to use a service on behalf of a client, you yourself should have an account at that service and the client should make sure your account has sufficient priveliges for you to do your work. Here you have a clean division or responsibilities - you are responsible for your own account.

In the real world, this is not always possible. You should avoid these situations as much as possible, and only take responsibility for other peoples passwords when you really have to. But let's face it, some times you just have to.

Then a password manager is the best solution. Some advice for how to use it:

  • Pick a good master password. And when I say good, I mean good.
  • Consider using an offline password manager, so no files uploaded to any servers anywhere.
  • 2FA (e.g. require a hardware token to decrypt) is also a good idea.
  • You may want to create separate accounts for each client. Only do this if it is feasible without compromising the quality of the master password.
  • Finally, be completely transparent with the person who's passwords you are handling. You want to make sure that they know and accept what you are doing. There are probably a ton of legal aspects to this as well, but unfortunately I have no insight into those.
1

In addition to the good information provided by @Anders, another possible setup (depending on your and your client's IT setup) is to eliminate the use of passwords altogether by switching to a SSH key based login method. There are some immediate benefits that I think of:

  • SSH keys are not human generated so insufficient entropy of passwords issue with passwords based authentication is eliminated.

  • The private SSH key can only be used from the device from which it was generated making attacks that exploit vulnerabilities of the endpoint used to login much more difficult as only 1 device needs to be hardened.

Of course, using SSH keys would require additional end user training and a more robust IT infrastructure, prerequisites that smaller vendor companies may not be able to achieve.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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