look at these morons:
https://github.com/checkr/supersecret/commit/6b9cdf366084318...
GitHub commit search: “remove password”
241–250 of 266 posts
Re: GitHub commit search: “remove password”
#242Earlier quoted context omitted.
Somehow I doubt Azure Key Vault is easier than a gitignore line and a text file
.gitignore is easy but the pw is still naked. Probably a good practice to hash it.
Probably not as the result would be useless for authenticating against another service.
Re: GitHub commit search: “remove password”
#243Too many comments here recommend to clean up the commit and just hide the mistake under the rug. This is wrong. If you leak a password to any public location, there is only one reasonable course of action: CHANGE IT! Don't even bother rewriting the commit. Focus on changing that password right away, and while you're at it, figure out a better way to manage your secrets outside of your source code in the future. Mista…
the solution is to store the password and any other sensitive information in a text file that you read when your program starts up. And don't forget to add that file's name to .gitignore so git will ignore it. As simple as that. :) If you leaked the password in the git repository, change it as @jvehent just commented.
Agreed that is good practice. Oftentimes though when you're prototyping something you aren't really thinking that much about the structure of the project, and then you end up accidentally committing passwords. But yeah, would be a good practice to have this deeply ingrained and just do it automatically for every similar situation.
Re: GitHub commit search: “remove password”
#244Earlier quoted context omitted.
Whoa, that's actually amazing. Wonder how they got alerted and reacted so fast.
Github provides a public firehose for events[0]. So it's possible to hook a process to read from the firehose, and look for commit events and then match file contents against the list of API keys. [0] - https://developer.github.com/v3/activity/events/
Yikes. So this is where the evil crawlers are sitting.
Reminds me of the water pipeline in Finding Nemo with the crabs above it.
Re: GitHub commit search: “remove password”
#245I set up a honeypot and made this commit: https://github.com/teaearlgraycold/honey/commit/7c4289717979...
Already had a couple of sassy individuals telling me my honeypot is shit via the tty logging.
Re: GitHub commit search: “remove password”
#246I set up a honeypot and made this commit: https://github.com/teaearlgraycold/honey/commit/7c4289717979... Already had a couple of sassy individuals telling me my honeypot is shit via the tty logging.
Fell for it, this is the first time I connected to a honeypot (or so I think). I especially liked the part where you type 'exit' and it just keeps you connected but the command line changed to 'root@localhost' at the beginning. Had a good laugh there :)
What software are you using?
Re: GitHub commit search: “remove password”
#247There are tools that automatically rewrite your git history and can fix this.
Re: GitHub commit search: “remove password”
#248can someone please give me an ELI5 breakdown of what I'm missing... did these people attempt to change their password via git commits?
Re: GitHub commit search: “remove password”
#249Earlier quoted context omitted.
I think its as important to make it "hard to do the wrong thing" as "easy to do the right thing". In this case having to explicitly exclude a file containing passwords from being deployed would fail that rule of thumb. The Azure Key Vault is a good solution that so far seems easy to work with (I've only just started using it though) and it can make the storage of secrets easier to secure but you still have the issue…
As you say, the Azure Key Vault helps making things more secure (by allowing to control, log and revoke keys usage), but it does not help at all with the problem of API keys in the source code - it's just another set of keys that you need in your config.
Sometimes! (Full disclosure: MS employee, big-time Azure user in a different group)
An AAD Application can act on behalf of a logged-in user (using OAuth2 or openid) with the correct delegated permissions. This means you can grant key/secret/certificate CRUD privileges to an AAD user or group, and then use OAuth to obtain a token granting access to the KeyVault resource. All activity is performed by the client (read: application) on behalf of the user (read: human) against the resource (read: key) without having to store any secrets at all.
I use the keyvault pretty extensively, and have really grown to like it.
Re: GitHub commit search: “remove password”
#250Earlier quoted context omitted.
There are lots of ways to handle those scenarios. Deciding where to store your secrets is extra easy if you're in the cloud. In AWS you can use KMS to store it if it's 4kb or less. A cli command or API call can decrypt it for you. If it's larger, you can use a tool such as credstash which lets KMS manage the keys. If you're in an environment that's using Chef, it can handle them. Ansible has a solution as well. Or yo…
Oh, yes, I didn't mean there wasn't a solution. We use Hashicorp Vault, for example. I simply meant that "store passwords in a file" (as mentioned in the post I replied to) is too simplistic to cover all scenarios.
Files are good because virtually anything can read and write them, so they are very portable. I used to work with a really great security guy who created a good system for handling secrets. He had us write them to files, but only to a tmpfs mount, so that they were written to memory and not disk. We also didn't write them to regular files, we used named pipes. This way the application on initialization would read a secret from the pipe and would block waiting for it to be available if it hadn't been written yet. There was a separate process in place to handle the retrieval of the secret and the writing of it to the pipe. As soon as it was written, the application would finish reading and continue its initialization. This ensured things happened in the correct order, and also made the file to be one-time-use.