How bad is it to store credentials in clear text on disk and in memory?

Question

Yeah, it depends. A good answer would provide some reflections on this. I have two concrete scenarios in mind, in two concrete (and I believe common) contexts. Context 1. At home, you’re the only one with access to the computer. Context 2, at work, you and anyone in the IT department have access to the computer.

When it comes to “secrets in-memory”, I have two things in mind. Storing too many secrets in memory, and the ability of user space applications to dump the memory of other processes.

• Scenario 1: GCP (and I believe AWS and Azure) stores all credentials used by the user in cleartext on disk. GCP stores keys and everything in a cleartext sqlite db. Let’s assume that the disk is encrypted at rest, but decrypted upon user login (this is what macOS FileVault would do, and I believe LUKS too)
• Scenario 2: 1Password, LastPass and other password managers decrypt and load all secrets to memory, master password included, upon application login, and they don't necessarily clean up upon application "lock". This was "revealed" a couple of years back in the Washington post; see this forum post for 1Password response. A notable exception is pass which is probably what you should use if you have the same concerns as listed in this question.

The tldr from 1Password is that protecting from attackers that have access to your system is nonsense, they could always intercept the keyboard for instance. While that’s true, I would feel very uncomfortable if all it took to steal my entire online identity was to simply dump the memory of a process. Anyone in the IT department could do that; installing a keylogger on the other hand, while possible, is much more intrusive. Dumping process memory is not straight forward with SIP enabled for macOS, but I don’t know what it would be like on Linux or Windows.

For cleartext credentials on disk, the consequence of these credentials falling into the wrong hands is very high for particular keys and access tokens. The company IT department is maybe not the greatest threat here, but this still feels like something you would want to have as part of a blind threat model (to reference GitLab’s threat model framework). For a lot of use cases, envchain and sops can solve this for you. I don’t think it’s that straight forward with cloud vendor credentials, primarily because secrets are stored in multiple databases, and every single client library that hard codes where to find the credentials would break.

So that's it. It seems clear that the modus operandi of a lot of companies is to break common sense security guidelines, keep secrets encrypted and only decrypt what you need. Could anyone provide some feedback on this train-of-thoughts and the conclusion? Is it really bad to have cleartext credentials on disk, and decrypt far more than what you need?

Answer 1

As you said "it depends". So there is not a definitive answer that can be used as one-size-fits-all. It is somewhat opinion-based as well, I'm afraid. The real solution is to do a risk analysis: an estimation of the probability that a password is stolen and the costs of that compromise versus the problem of all that software, encryption etc.

Passwords should be secret, that is the basic premises. How secret depends on what the password is used for. My bank's password is extremely secret and I've used a random password generator to create it. However, there are sites that require you to "register" and choose a password before you can read a white-paper. There my password would be "Secret123!" or something like that (and 10minutemail for a mail address).

Is the password shared between sites (some people call this "password synchronization")? If you use your facebook-account to log-in on other sites as well, that makes your facebook account probably more sensitive than if it is used for facebook only. On the other hand, if you use a different password for all sites, you need some way of tracking all those passwords; some kind of storage most likely.

The result of a compromised password is also less if you use multi-factor authentication. True, if you previously had uid, password and fingerprint, that will effectively become uid plus fingerprint of the password is compromised, but your data will still be relatively inaccessible.

Are you warned if there is a strange login? Google does this if you log-in from a different device, but even a simple SMS verification will signal that your password is compromised. This will reduce the impact of a compromised password, if you react quickly enough.

I don't know your IT staff, but if they are the type BOFH, I certainly would not store passwords, even encrypted, on my work computer. If they are more professional, you might use an encrypted storage, but in general I don't use my work computer for that. For the rest of the answer, I will allow myself some musings, that may help you with the risk analysis.

Password managers load all passwords in clear text in memory. That is bad (probably), but how bad is it? Does your IT staff (or anyone else for that matter) get memory dumps? Are people allowed to run software that reads the physical memory on your work computer? Normal programs do not have that kind of access. So, it is either a sophisticated hacker (in which case you have a lot more problems) or some IT forensics expert from a government abbreviation that reads your memory.

If no-one ever has access to your private computer (except you), then storing in clear text is no problem. But you may have burglars, and even though the burglars may not hack you, someone who buys the computer from them may. So you will need a contingency plan.

So what is you contingency plan? For most of us, it is changing the passwords of the compromised sites. Do you have an idea how much time that takes? Do you know how to reach your bank to block transfers until you've reste your passwords?

How much trouble is it to encrypt your passwords on disk? If you use LUKS anyway, than by all means, store the passwords on a LUKS encrypted file system. Password managers in general are fairly easy to use. If you want one that decrypts only the secret that you use, that will take at least an hour in Perl to get an acceptable one. But if you're not much into programming, a standard password manager would do just fine.

So, there are some points to consider. Using two-factor will have the biggest impact, probably, but ymmv.