Re:How a bug in VS2015 exposed my source code on GitHub and ...
by cptnbob on Monday August 31, 2015 @06:34PM
(#10149533)
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/Developer...
Re:How a bug in VS2015 exposed my source code on GitHub and ...
by nailer on Monday August 31, 2015 @06:26PM
(#10149496)
> 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?
Re:How a bug in VS2015 exposed my source code on GitHub and ...
by voltagex_ on Monday August 31, 2015 @07:15PM
(#10149711)
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.
Re:How a bug in VS2015 exposed my source code on GitHub and ...
by wereHamster on Monday August 31, 2015 @11:47PM
(#10150615)
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.
> 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.