Better question:

As a system administrator, how does one find issues like "improper logging that leads to credential capture"? And how do es one find credentials for internal services crammed in and hidden in old crufty source tomes?

Obviously, when you find it, you nuke the creds, change them, and fix it. But you can't automate, because that requires the raw data. And if you hash the passwords, you end up having to hash everything in order to perhaps find the bad hashes. And when dealing with MBs/s of log, you can't offset-hash everything to scan... and you're back to raw text-matching passwords..

How do others do this, so we can do the right thing?

> Obviously, when you find it, you nuke the creds, change them, and fix it.

The status quo is to toggle a boolean on their account. If they sign in and this boolean is true, then don't actually sign them in. Tell them they need to change their password first.

Then you'd send out an email to the account holder to change their password. If they actually own the email, and aren't an imposter, then you're good to go.

So in terms of automation, it's literally just a boolean check during log ins, and make sure you're actually doing password resets correctly.

You've reduced the scope of my original question, to that of compromised accounts. My question is a magnitude larger than that.

For example, someone checks in code and left a config file semi-populated which included a live login credential. Obviously the answer is "Dont do that!" but we all are human. People accidentally post apikeys, credentials and other secure things. It happens.

But how do you automatically find issues like this? If PII is radioactive, credentials are gamma-emitters.

We solved this at a job long ago with a list of plaintext passwords on a machine you couldn't log into except local (butt-in-seat), and it took your SVN commit, scanned it, and gave a pass/fail. That methodology at least stopped our internal shared service accounts from being accidentally compromised.

Though if you guys primarily use Git, this does wonders: https://github.com/zricethezav/gitleaks

The only thing I can think of that would help prevent credential compromises is to either implement a company password manager (akin to your butt-in-seat solution) with an ACL, and only accessible on the local network. That shouldn't be too much friction for employees to actually utilize it.

Next is having a secure channel to transmit secrets. That + Password manager has personally helped stop my coworkers in the past from sending passwords in emails, slack messages, post-it notes, text files on their computer, a committed file in a repo, etc.