201–210 of 266 posts
Earlier quoted context omitted.
Why not both? :)
That's time you could be spending on adding a new feature or fixing a bug :) Just change the secret and be done with it!
Earlier 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…
Kms doesn't have a size limit if used right. You should use kms to store a key and store the data on s3 encrypted.
Earlier quoted context omitted.
It is customer fault. However it should be pretty easy for them to set up a script to search github for this kind of stuff and automatically invalidate keys
At my work one of my coworkers accidentally put a secret token in a GitHub issue. Couple hours later he got an email from the sysadmin at the parent company saying his token finding script went off. He probably wouldn't have noticed for a long while if that script wasn't running.
Throw the word 'oops' in for good measure. https://github.com/search?p=2&q=remove+password+oops&ref=sea...
Even more frightening: https://github.com/search?utf8=&q=id_rsa&type=Commits&ref=se...
Wow private keys just sitting in plain sight o.O
Earlier quoted context omitted.
Whoa, that's actually amazing. Wonder how they got alerted and reacted so fast.
It's cheaper for them to give a few engineers a web crawler project that's this specific than it is to refund people. Im just surprised they don't have an "auto revoke access key if found on interwebz" setting in the AWS account settings actually.
- a key is made public, and we have to call a user or refund them (for retention purposes)
- a key is made public, and we revoked the key, potentially breaking the customers builds/deploys and potentially knocking a customers stuff out (if, for example, a key is disabled during a push to production).
Earlier quoted context omitted.
On an internal VCS this may be a deliberate decision: Secrets need to be stored somewhere and a cost-risk analysis can result in "this is the best place that we currently have at our disposal". That obviously won't fly if your threat model includes "adversary may attack our github account from within GH" or if you ever plan on opening up that repo, but if neither applies this may be the best place to store some sorts…
Sure there's always a cost / benefit balance to take into account. That said I'd say putting secrets in a git repo is a pretty risky thing to do. By the nature of the tool that means that the secret ends up on the device(s) of every developer who checks out the codebase, so the security of the secrets is equal to the security of the worst secured device in question.
Storing and keeping secrets is a pretty risky thing in general. Think: small team, small app, everybody has the secrets anyways for deployment purposes. Sure, setting up vault is superior - but how much effort does that cost that could be invested in a better solution. Or a puppet repo that you use to provision your machines, shared in the ops team: small team, everbody has root - on each machine there might be an ssh key that gives away all your secrets. So better invest in solid FDE and maybe tie that to a TF device, a yubikey that is required to decrypt the disk etc. Not perfect by all means, but there's limited time to go around and you really should think about what threats you want/can defend against. (for example, for most projects, I'm not wasting any thought about defenses against a nation state actor, that's a threat that I won't be able to meaningfully counter anyways).
Earlier 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…
Kms doesn't have a size limit if used right. You should use kms to store a key and store the data on s3 encrypted.
Too 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.
I'm drafting a writeup and will post it to HN when that's ready. Other secrets managers I've seen posted to HN seem far too overcomplicated, at least for our company's needs. This is a step up from reading secrets from a plain text file, but not so complicated that you need a separate docker image running a service dealing out passwords to your webapps or similar.
EDIT: rationale for use, as requested:
Using this approach, you can better manage your secrets since you can actually commit the passwords file in your code base, and the API lends itself to easily switching between dev and production ids/secrets. You can track revisions to the secrets file, rolling back your commits rolls back the secrets as well. You can also include the deployment of secrets in your deployment script - typically, the encryption key for your vault is only generated and distributed to the production servers once, while secrets may be added, changed, and removed continuously during the development and product lifecycles.
Using a simple secrets manager like NeoSmart's SecureStore lets you embrace the benefits of deployment automation, revision control, and more, without sacrificing safety and security in the name of productivity or ease-of-use.
EDIT2: what the heck, just took 10 minutes off to write it up and publish it: https://news.ycombinator.com/item?id=13654005