Re:When a bad day gets worse – getting hacked twice in one day
by jaryd on Tuesday May 06, 2014 @01:20PM
(#7705822)
Looks like a good opportunity for an open source tool that scans a git repository for interesting/private information. Obviously it could be used for nefarious purposes, but it would be helpful for anyone looking to open source an existing repo.
Another alternative is to store credentials in environment variables :)
Re:When a bad day gets worse – getting hacked twice in one day
by moot on Tuesday May 06, 2014 @01:29PM
(#7705878)
> Looks like a good opportunity for an open source tool that scans a git repository for interesting/private information.
These already exist in droves, which is exactly how our Amazon credentials were found.
http://www.itnews.com.au/News/375785,aws-urges-developers-to...
Re:When a bad day gets worse – getting hacked twice in one day
by jdhendrickson on Tuesday May 06, 2014 @02:53PM
(#7706382)
I wasn't cognizant of the need to include a step in which you scan your own repo, just as a fail safe. So thanks for posting this.
Re:When a bad day gets worse – getting hacked twice in one day
by yeukhon on Tuesday May 06, 2014 @07:33PM
(#7707805)
Time for this question to come back live.
http://security.stackexchange.com/questions/56911/does-anyon...
Anyone has any idea about this website I am trying to find?
Re:When a bad day gets worse – getting hacked twice in one day
by ufmace on Tuesday May 06, 2014 @01:55PM
(#7706037)
Probably a good practice. For my current project, I've been careful to never commit any API credentials or other secrets to the repo, even though I don't currently have any intention of making it public. It's harder to know what you're missing, though.
Re:When a bad day gets worse – getting hacked twice in one day
by cycojesus on Tuesday May 06, 2014 @03:20PM
(#7706528)
How about a commit hook that warns when it looks like you're about to commit a secret key?
Re:When a bad day gets worse – getting hacked twice in one day
by Mikushi on Wednesday May 07, 2014 @11:33AM
(#7710720)
Did something similar, just built a module for our CI tool that checks against sensitive information (secret, salts, hashs, hidden feature), pretty efficient as every dev (myself included) can get lazy and use keys directly in scripts, instead of our Config loader that safely retrieves all that.
Not bad in itself, sometimes all you need is a dirty script, but as other have said, they tend to stick around, a key part of our CI module is actually putting expire date on scripts, or check dates. I will receive an email telling me to check and a warning on the CI at build time. It's been great to keep our code clean while allowing us to still do things dirty when required.
Or maybe just a rant on PHP and/or frameworks that make it easy to do the wrong thing, and hard or time-consuming to do the right thing.