5 ms·

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 credentia

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?

prophesi 8y ago
> 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.
- crankylinuxuser 8y ago
  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.
  - prophesi 8y ago
    Ah, sorry about that. I got hung up on the second half of your post. Can't say I can think of a good automated solution for bad security hygiene among employees. :/ Though if you guys primarily use Git, this does wonders: https://github.com/zricethezav/gitleaks 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.
    - crankylinuxuser 8y ago
      That's fine, it happens :) Yeah we've seen that git module. We use something similar to that. I was also thinking inadvertent log capture as well. Capturing creds in an ELK stack is just as bad. And I'm guessing this FB issue is some variation of complete logging snarfing creds. I'm just trying to think of coherent ways we can scan, detect, and act on creds that work across a backend. Seems to be a rather large hole.

prophesi 8y ago

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

crankylinuxuser 8y ago
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.
- prophesi 8y ago
  Ah, sorry about that. I got hung up on the second half of your post. Can't say I can think of a good automated solution for bad security hygiene among employees. :/ Though if you guys primarily use Git, this does wonders: https://github.com/zricethezav/gitleaks 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.
  - crankylinuxuser 8y ago
    That's fine, it happens :) Yeah we've seen that git module. We use something similar to that. I was also thinking inadvertent log capture as well. Capturing creds in an ELK stack is just as bad. And I'm guessing this FB issue is some variation of complete logging snarfing creds. I'm just trying to think of coherent ways we can scan, detect, and act on creds that work across a backend. Seems to be a rather large hole.