5 ms·

> Wouldn't that that imply every secret accidentally committed and then 'deleted' is still accessible This should be a moot point because anyone (in IT) should

• soulofmischief 8y ago
  Security isn't rendered in absolutes. We have to assume some sheepish new employee somewhere is scared of approaching management about a mistake they made committing a secret, so they reverse the commit and pretend nothing ever happened. We have to try and mitigate damage from lapses in communication and protocol like that.
  • iakh 8y ago
    In either case, the secret is already out whether the user wants to admit to it or not
    • soulofmischief 8y ago
      But in one case, damage is mitigated because the sys admins didn't assume everyone is infallible and strictly adheres to protocol.
      • danharaj 8y ago
        The correct way to deal with fallibility in this situation is to make it feasible to change secrets when they leak, not pretend they weren't leaked.
        • soulofmischief 8y ago
          That doesn't prevent someone from not following protocol.
          • _II__II_ 8y ago
            It's not their job to prevent that.
            • soulofmischief 8y ago
              It is a sys admin's job to mitigate damage from security leaks and to introduce hardened, fault-tolerant security paradigms.
              • mkagenius 8y ago
                You are just hacking the leaves. Once the secret is posted. It is public, it has multiple copy elsewhere on the internet. Even if you delete there is a copy kept somewhere on the internet -- and that's not an assumption. For example, iirc, Github copy is dumped to google every some-x-time.
                • justinclift 8y ago
                  Hmmm, it seems like having layered security, where accidentally exposed credentials aren't automatically "game over" would be better than not. Not sure how practical that is to implement for every technology, but for many it could probably be done. Seems like a time+money vs risk trade off thing.
      • wybiral 8y ago
        Is it mitigated? Once it's leaked you can't force everyone who may have captured it to delete it. So GitHub deleting it doesn't solve the problem.
        • soulofmischief 8y ago
          The definition of mitigation is to make something less severe. Yes, GitHub making this policy as clear as possible and allowing controls to toggle it per-repository or per-account mitigates the problem.
  • trickstra 8y ago
    Math and cryptography don't care about a sheepish new employee (thankfully). The fact that leaked secrets will cause trouble is not mitigated by git forgetting a deleted commit. It is only mitigated by revoking that secret and creating a new one and not leaking it. So if a sheepish new employee fails to revoke them, why blame git or any other system? We have contracts, insurance and then criminal code for people who fail to follow protocols.
    • soulofmischief 8y ago
      No need for any git-blame, the blame lies in GitHub not making this feature optional and more known. So well known that a noobish employee is aware of it, so that they do not feel like they are "safe" and no longer need to alert management about their error. Contracts, insurance and criminal code are responsive measures, not preventative measures. Security is preventative, not responsive.
      • justinclift 8y ago
        > the blame lies in GitHub not making this feature optional and more known. Which feature are you meaning should be optional and more known?
    • asdfasgasdgasdg 8y ago
      The criminal code? I doubt there's anything in there that criminalizes a failure to follow an employer's secret revocation policies.
      • trickstra 8y ago
        No, I wasn't referring specifically to this case. Generally, if people don't "follow the protocol", we have criminal code. If machines don't follow protocol, they end up with wrongly decrypted garbage data. It was to highlight the point that we have different measures to deal with people than we have with computer security, because math cannot prevent people from deviating from their protocols.
    • 8y ago
  • JeremyBanks 8y ago
    I agree with the general statement about security absolutism (it's often very dumb and irrational), but in ths case in particular, most keys are swept from GitHub within seconds of being pushed, so the additional harm of not pruning those commits is very low. Data loss concerns are probably a much larger source of harm to weigh against it.
    • soulofmischief 8y ago
      Well now I would say that I'm not interested in most keys, and I am interested in figuring out how to mitigate damage from the rest of them. You only need one key to get inside. 99% coverage is not good enough from a security standpoint, not when we can achieve 100%. Simply, this functionality should be transparent and toggleable.
      • JeremyBanks 8y ago
        deleted
        • soulofmischief 8y ago
          I think you're confused about what absolutism means. Just because I want 100% coverage when achievable does not mean I am being absolutist.
  • paulddraper 8y ago
    Yes and this is why Github handicapped their search so much. But at the end of the day, any secret you post publicly is compromised.
    • soulofmischief 8y ago
      Thankfully the guys over at Sourcegraph feel differently about how searchable projects should be.
    • manigandham 8y ago
      That's a very poor reason to not have good searching functionality considering the uses far outweighs the potential risk. I highly doubt it's the case.
      • paulddraper 8y ago
        I'm 90% sure it is. GitHub had great search, then they took it down when they found people we're scraping credentials with it, then they had bad search. I'm connecting the dots.
• bostik 8y ago
  And a hundred times so for any public repos. There are bots feeding on the GitHub firehose, scavenging for accidentally committed credentials. A few years back (2015 or so) the average time from push-to-repo to AWS account compromise was 6 minutes. Surely that time has only gone down, and the number of different credentials identified has gone up.
  • username223 8y ago
    > the average time from push-to-repo to AWS account compromise was 6 minutes. Wow, I didn't realize it had become so efficient, but I shouldn't be surprised. I never really understood the value in hosting non-public software in the public, and if it's open source, it shouldn't be getting anywhere near secrets that can be used to extract money from its developers. I remember thinking, back when it became trendy for people to upload their personal dotfiles to Github, that it would be a source of endless suffering. Who knows what information you're leaking in your ".profile" or ".bashrc"? Is that risk justified by the dubious benefit of storing your dotfiles on the internet for everyone to see, forever?
    • tjr225 8y ago
      I had accidentally pushed an AWS credential out a month or two ago- within about a minute and a half AWS had disabled the IAM user, and automatically emailed me(as well as my entire org- how embarrassing!)- when we were going through the access logs it looked like it had taken only a minute and a half longer for some other, presumably malicious, system to attempt to access my compromised user. Probably between 2 or 3 minutes total. I'm not a huge Amazon fan but props to AWS for saving my butt.
      • scarface74 8y ago
        Why have credentials anywhere outside of the .aws directory in your home directory? When developing locally all of the SDKs will read them from there and when deploying to AWS, the SDK will get them from the attached role.