3

For customer support reasons, we need to store passwords to some of our customers' systems (with their explicit, written permission, of course), as well as, obviously, passwords to some of our own systems. Customer support agents and administrators need to be able to access those passwords.

I am aware that - despite all our efforts to the contrary - it might only be a matter of time before one of the PCs in my company's network gets infected with malware.¹ When that happens, I want to minimize the damage. In particular, I want to minimize the number of passwords that gets leaked.

Classic password managers don't help here. They help against password reuse and other dangers, but they are not designed to mitigate that kind of threat. On the contrary: The customer support guy's PC is compromised, they enter the master password to their password manager and... bang... the bad guys have won the jackpot.

I am looking for a solution to ensure that only as few passwords as possible (ideally, only the passwords actively used during the time period between the PC being compromised and the attack being detected) are leaked.

Obviously, storing the passwords on paper² instead of a password manager would solve this, but I would also like for the solution to be practical (the paper solution won't work if the users are in pandemic-induced home office, for example). Another option might be an online password manager which "rate limits" the number of passwords that can be accessed per hour (and sends out e-mail alerts when too many password are requested).

I don't want to reinvent the wheel, and I'm sure that other companies have the same issue. Is there any "canonical" or at least widely-used and established solution to this issue?


¹ If you google for "percentage of companies having been hacked" or "percentage of companies having been infected with malware", you get various news articles on the first page claiming various two-digit percentage rates. I don't want to get hung up on a particular number, I just want want to illustrate that the risk is real and much, much more likely than "rubber hosing" or something similar.

² To clarify the threat model: I am concerned about hackers on the other side of the world having a "lucky day" (i.e., an employee starting a malicious file which somehow managed to get through all our filters), getting into our network and then seeing what they can harvest before doing their usual ransomware stuff (yes, we do have backups). I am not concerned about targeted and/or physical attacks by state actors (fortunately, we are not important enough, and neither are our customers).

Heinzi
  • 2,914
  • 2
  • 21
  • 25

4 Answers4

1

This is exactly the threat that standards such as FIDO and WebAuthn aim to mitigate. These standards use public key authentication to authenticate with web sites and other services, using a private key that is stored on a device (such as YubiKey).

The private key never leaves the device, so even if the computer is compromised, the attacker is not able to access the private key.

Adoption has been gradual, but a fair number of sites support these standards now. Some of them are listed at https://www.yubico.com/about/reference-customers/.

mti2935
  • 19,868
  • 2
  • 45
  • 64
  • 1
    This requires customers supporting FIDO / WebAuthn in their system and provide access through that. Both are in their infancy in terms of adaption, especially for small businesses – K4M Aug 02 '20 at 18:59
1

You can split the passwords into two pieces. Keep one piece in your password manager and make it complex (local or cloud or browser - each has its own pros/cons).

Keep the second piece easy to type but not necessarily short and make it unique to each of your customers. Keep this list in another place (Google spreadsheet - or printed if same customer has many users, your "per customer" list can be short to print)

This will expose limited number of customer passwords, in terms of the second piece.

But, if you keep the second piece electronically (cloud or local) accessible on the same computer, a determined adversary could still observe the actions of your employees and figure out the source for the second piece. There is no way to avoid that.

If your customer's systems supports 2nd form of authentication, you can request them to enable as well. That can devoid the need to have a second piece for that customer.

WebAuthn technology is coming but not here yet in terms of adoption. Since you're asking about passwords from your customer owned systems, unless they support these technologies, you cannot use utilize them. It's up-to your customer to deploy these newer technologies.

You could require your employees to use a YubiKey to access the passwords manager (not all supports) but this doesn't solve the problem if the password manager opens access to all passwords all at once. If you can find a password manager that can require YubiKey on each and every password access, then this will be your ultimate solution.

I haven't shopped recently so I don't which one does do that. You can check out Dashlane which supports YubiKey. You can even use Gmail, which supports YubiKey and stores your passwords in your account (with a master password Google can't see your password as well) but I think it keeps all passwords locally secured by your computer login password. So it's possible a malicious actor could access them all after YubiKey.

Sorry, that's all I could think of.

K4M
  • 542
  • 3
  • 8
1

This is a problem I've been trying to solve for a while, but I'm not ready to share a complete solution, since I'm still working on it. For now, I will only share some details and general principles.

The problem of password managers is that they introduce a single point of failure, that is, once your machine is infected all the passwords might be used by the attacker. 2FA is not always effective when your own system has been compromised, and 2FA in many cases might still not be available.

My solution involves making passwords unavailable without an external source that must never be connected to the machine. In practice, this means you would need something written on paper, or an app on a device that will never been attached to your machine. When your machine is infected, the attacker must not be able to get all the passwords, which implies that some information must be stored externally and never be fully accessible from your machine.

In practice this could mean that you need to use a password manager with multiple encrypted databases and a different master password for each encrypted database. You could use a different database for each customer, for example. This way, if your machine is compromised and you realize it's infected after 1 week, a customer will be at risk only if you have accessed their passwords in the last week (by unlocking their dedicated DB). Other customers or accounts will be safe, because you have never unlocked their DBs (and the master passwords to unlock them is not accessible in any way from your machine).

Problems

The more separate DBs you use, the better, which means that in theory you might even end up with a different DB and a different master password for each password (making password managers basically useless, like using a password manager to manage a single password). On the other hand, grouping too many passwords together in the same DB will increase the chances of compromise.

The other problem is that keeping all the master passwords on paper will make backups difficult. At the moment, my proposed solution for this is to generate master passwords with an algorithm that uses hash functions (like key derivation functions), so it cannot be inverted. In other words, by knowing the "root password" that generates all the master passwords, it is easy to generate a list of all the master passwords, so it's easy to create backup copies even if you lose your list on paper. And an attacker, by knowing one master password, cannot guess the other master passwords easily, for the same reason why they cannot easily guess hash(root_password + 1) was generated by just adding 1 to hash(root_password).

reed
  • 15,398
  • 6
  • 43
  • 64
0

Disclaimer: I am not affiliated in anyway with Yubico, neither have I tried the products listed on the web-page below. This is not an endorsement of any of those companies.

Related to mti2935's answer about the use of YubiKeys, it appears from the section Works with YubiKey: Securing Password Managers on Yubico's website that there are at least a couple of Password Managers that work with YubiKeys. From that page:

Using a YubiKey for 2FA with your password manager ensures that even if your master password is compromised, the rest of your passwords are still secure.

While I've not tried either of the two products currently listed (nor delved deeper into their technical details), the implication is that by using a YubiKey, a compromise of the Master Password is no longer a case of "bang... the bad guys have won the jackpot.".

TripeHound
  • 1,151
  • 8
  • 11
  • 1
    But once you insert the YubiKey or use any kind of 2FA to unlock your password manager, aren't all passwords accessible from a compromised machine? That's the problem. The first time you need to unlock the password manager to get one password (which might happen within minutes of an infection anyway, or multiple times a day), all the password are exposed. – reed Aug 03 '20 at 14:41
  • From the bit I quoted, and the rest of their page, I ass.u.me not, but I admit I don't know the details. If the private key is on the Yubi, exfiltrating the password database won't help, and _perhaps_ each use of a password needs the Yubi to be pressed. If I get a chance, I'll see if I can dig deeper into how they work. – TripeHound Aug 03 '20 at 14:55