4 ms·

"As a senior developer with over 12 years of experience in the financial services industry, I didn't think it was possible that I could be the victim of a data

"As a senior developer with over 12 years of experience in the financial services industry, I didn't think it was possible that I could be the victim of a data breach." We're only one sentence in and I'm already very, very nervous about the author's hubris.

forrestthewoods 11y ago
I took it less as hubris and more of a way to imply to readers that no matter their experience they are not immune to the mistake he is going to tell you about.
- merlincorey 11y ago
  I think it's definitely some hubris, because the mistake he made wasn't publishing to github publicly by accident. It was thinking a git repository was a good place to store secrets.
merlincorey 11y ago
Thankfully, the author realizes later what it they really did wrong here: > What could be done to prevent this? > Always test new version control GUIs before using them in the wild. There could be a bug that could expose your data. > Encrypt access keys in config files instead of just leaving them exposed in the config file. > Better yet, move access keys to a seperate config file, and exclude this from Git deploys with a .gitignore. The fact this supposedly security experienced and conscious developer thought it was okay to have any kind of access credentials stored in a git repository is glaring. You should consider all data in any repository public for security reasons. Publishing to github publicly made it quite obvious - but he could have been just as screwed over by people he gave access to the private repositories and people who have broken into github and can directly access the repositories. Sure the numbers on both those groups are lower than the numbers of people apparently scanning public github for access keys - but the severity of the risk of keeping access keys and other secrets in your revision control are the same.
- nailer 11y ago
  > Encrypt access keys in config files instead of just leaving them exposed in the config file. How do decrypt them when you app re-launches? How do you decrypt them automatically on every instance?
  - voltagex_ 11y ago
    I've moved to using environment variables. I realise they have their own security challenges but at least I'm not accidentally going to git push the keys.
    - wereHamster 11y ago
      But you probably want to store the descriptions of the instances and what runs on them in a git repository. It doesn't matter whether you use env variables or something else. At some point you will have a git repository which stores the CM for your whole infrastructure.
- cptnbob 11y ago
  He could also separate code and configuration as per the docs but I suspect the hubris excludes bothering to read them...: http://docs.aws.amazon.com/AWSSdkDocsNET/latest/V3/DeveloperGuide/net-dg-config-creds.html http://docs.aws.amazon.com/AWSSdkDocsNET/latest/V3/Developer...
ProAm 11y ago
Why? It sounded like he is very security conscious. Thought he was creating a private repo in VS, immediately after he was notified deleted and recreated his keys. A pretty spot on course of action I think.
- famousactress 11y ago
  Because anyone who ever says "I didn't think it was possible that I could be the victim of a data breach" is dangerously delusional, and in case I'm not being clear - wrong. Also putting keys in (even a private) cloud-hosted repos is at least a step under what I'd describe as "very security conscious" for someone who self describes as working in the financial industry.
- cptnbob 11y ago
  1. He stored credentials in source control rather than using configuration profiles as specified in the AWS SDK documentation. 2. He pushed code to a new repository without verifying the security configuration of the created repository (granted the tool made it easy to do this but you should create a repo, verify it, then push code). 3. He used his master AWS account key/secret in the code which gave global access to everything. 4. He didn't use IAM credentials with a restrictive policy set to just access the resources required. No, clearly not security concious. I'm a solution architect in the financial services industry and have been for 16 years. Never do I assume I know what the hell I'm doing.
tomphoolery 11y ago
Right? Who spends 12 years in the software industry and doesn't actually test their work after doing shit?
- nailer 11y ago
  Do you test the functionality of your git client or code editor? I personally generally expect them to work, as do most people.
  - mercora 11y ago
    On first use, i guess i have checked these parts one way or another. To assume things work the way you expect them might be the reason the bug was present in VS (if it ever actually was).

forrestthewoods 11y ago

I took it less as hubris and more of a way to imply to readers that no matter their experience they are not immune to the mistake he is going to tell you about.

merlincorey 11y ago
I think it's definitely some hubris, because the mistake he made wasn't publishing to github publicly by accident. It was thinking a git repository was a good place to store secrets.

merlincorey 11y ago

Thankfully, the author realizes later what it they really did wrong here: > What could be done to prevent this? > Always test new version control GUIs before using them in the wild. There could be a bug that could expose your data. > Encrypt access keys in config files instead of just leaving them exposed in the config file. > Better yet, move access keys to a seperate config file, and exclude this from Git deploys with a .gitignore. The fact this supposedly security experienced and conscious developer thought it was okay to have any kind of access credentials stored in a git repository is glaring. You should consider all data in any repository public for security reasons. Publishing to github publicly made it quite obvious - but he could have been just as screwed over by people he gave access to the private repositories and people who have broken into github and can directly access the repositories. Sure the numbers on both those groups are lower than the numbers of people apparently scanning public github for access keys - but the severity of the risk of keeping access keys and other secrets in your revision control are the same.

nailer 11y ago
> Encrypt access keys in config files instead of just leaving them exposed in the config file. How do decrypt them when you app re-launches? How do you decrypt them automatically on every instance?
- voltagex_ 11y ago
  I've moved to using environment variables. I realise they have their own security challenges but at least I'm not accidentally going to git push the keys.
  - wereHamster 11y ago
    But you probably want to store the descriptions of the instances and what runs on them in a git repository. It doesn't matter whether you use env variables or something else. At some point you will have a git repository which stores the CM for your whole infrastructure.
cptnbob 11y ago
He could also separate code and configuration as per the docs but I suspect the hubris excludes bothering to read them...: http://docs.aws.amazon.com/AWSSdkDocsNET/latest/V3/DeveloperGuide/net-dg-config-creds.html http://docs.aws.amazon.com/AWSSdkDocsNET/latest/V3/Developer...

ProAm 11y ago

Why? It sounded like he is very security conscious. Thought he was creating a private repo in VS, immediately after he was notified deleted and recreated his keys. A pretty spot on course of action I think.

famousactress 11y ago
Because anyone who ever says "I didn't think it was possible that I could be the victim of a data breach" is dangerously delusional, and in case I'm not being clear - wrong. Also putting keys in (even a private) cloud-hosted repos is at least a step under what I'd describe as "very security conscious" for someone who self describes as working in the financial industry.
cptnbob 11y ago
1. He stored credentials in source control rather than using configuration profiles as specified in the AWS SDK documentation. 2. He pushed code to a new repository without verifying the security configuration of the created repository (granted the tool made it easy to do this but you should create a repo, verify it, then push code). 3. He used his master AWS account key/secret in the code which gave global access to everything. 4. He didn't use IAM credentials with a restrictive policy set to just access the resources required. No, clearly not security concious. I'm a solution architect in the financial services industry and have been for 16 years. Never do I assume I know what the hell I'm doing.

tomphoolery 11y ago

Right? Who spends 12 years in the software industry and doesn't actually test their work after doing shit?

nailer 11y ago
Do you test the functionality of your git client or code editor? I personally generally expect them to work, as do most people.
- mercora 11y ago
  On first use, i guess i have checked these parts one way or another. To assume things work the way you expect them might be the reason the bug was present in VS (if it ever actually was).