7 ms·

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,

by jvehent 10y ago

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. Mistakes happen, but they shouldn't be repeated.

Kunix 10y ago
Blackbox is one good way to store secrets: https://github.com/StackExchange/blackbox https://github.com/StackExchange/blackbox
libeclipse 10y ago
I've only ever leaked a webhook, realised minutes later, and then changed the webhook URL on the backend. It's not hard to do, and doing anything else is simply really crappy security through obscurity while hoping for the best.
- thecrazyone 10y ago
  Why would a webhook URL be a secret? Wouldn't it be more like internal API if anything? I would assume that the parameters sent to the webhook, an auth token or something of the sort would take care of the security bit. Obscuring the URL seems like security-by-obscurity no?
  - ksenzee 10y ago
    For purposes of security, there's no difference between example.com/api/my-webhook?auth-token=[some-uuid] and example.com/api/my-webhook/[some-uuid].
  - olalonde 10y ago
    Not if you treat the secret URL like a password. Plus, not all webhook callers allow you to authenticate them without supplying them a special URL.
typetypetype 10y ago
100% agree with this. Not worth the hassle to do anything else.
olegkikin 10y ago
But what if your codebase is used in thousands of places that you don't control? You can't always change it. The real lesson is - don't put passwords in your code.
- vbezhenar 10y ago
  Using the same password in thounsands of places isn't good either. Use unique random passwords.
- tetrep 10y ago
  Don't use passwords/secrets/credentials that you can't rotate. If you've created a product in such a way that you can't rotate secrets, you have a large security issue that you should fix ASAP. It's like someone responding to the suggestion to "use strong/unique passwords" with "but what if I don't have any authentication?"
brettdong 10y ago
Completely agree. There are forks, mirrors and crawlers on GitHub, even you rewrite the commit and force push to GitHub server, the original commit data still exists in the forks and mirrors, and in fact anyone can even view the original commit in your own repo if they know its commit hash.
chmike 10y ago
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.
- shimo5037 10y ago
  It can be slightly more complex than that if you use a package manager to publish your work. I once accidentally leaked a password due to having both a .gitignore and an .npmignore, and forgetting to include my .env file in the latter. Fortunately, I realized what had happened almost immediately and was able to change the password. Now I tend to `tar tf` everything before publishing.
  - gkya 10y ago
    I believe that it's better to not have that kind of sensitive files be dotfiles.
  - matt_kantor 10y ago
    Because of issues like this I tend to set up my deploy scripts to first `git clone` into a temporary directory, then do the rest of the work from there.
- lloydde 10y ago
  Or environmental variables loaded at provisioning though this just moves the target. But these options do not themselves have the "in motion" characteristics that provide the best reliability, scalability and security. If your needs are more sophisticated this means keyservers where hardware security module (HSM) might by part of the equation.
- the_af 10y ago
  Agreed that you absolutely cannot store sensitive passwords in your source code repo. Your proposed solution, however, has its own share of problems for some deployment scenarios. Where do you get this file from? Assuming you are meant to place it by hand each time you deploy your application... what about autoscaling? What if you want unattended deployment of apps?
lholden 10y ago
Very much this. The first thing you should be doing is making the password useless by changing it. Doing anything else is entirely irresponsible. Sure, remove the file in question after that... but you can't treat the old password as anything other than public knowledge at that point.
muyuu 10y ago
Reminds me of the Bitcoinica fiasco. Stuff happens, especially under pressure. But yeah, if that happens to you, there is no more reasonable course of action than changing it right away.

by jvehent 10y ago

Kunix 10y ago

Blackbox is one good way to store secrets: https://github.com/StackExchange/blackbox https://github.com/StackExchange/blackbox

libeclipse 10y ago

I've only ever leaked a webhook, realised minutes later, and then changed the webhook URL on the backend. It's not hard to do, and doing anything else is simply really crappy security through obscurity while hoping for the best.

thecrazyone 10y ago
Why would a webhook URL be a secret? Wouldn't it be more like internal API if anything? I would assume that the parameters sent to the webhook, an auth token or something of the sort would take care of the security bit. Obscuring the URL seems like security-by-obscurity no?
- ksenzee 10y ago
  For purposes of security, there's no difference between example.com/api/my-webhook?auth-token=[some-uuid] and example.com/api/my-webhook/[some-uuid].
- olalonde 10y ago
  Not if you treat the secret URL like a password. Plus, not all webhook callers allow you to authenticate them without supplying them a special URL.

typetypetype 10y ago

100% agree with this. Not worth the hassle to do anything else.

olegkikin 10y ago

But what if your codebase is used in thousands of places that you don't control? You can't always change it. The real lesson is - don't put passwords in your code.

vbezhenar 10y ago
Using the same password in thounsands of places isn't good either. Use unique random passwords.
tetrep 10y ago
Don't use passwords/secrets/credentials that you can't rotate. If you've created a product in such a way that you can't rotate secrets, you have a large security issue that you should fix ASAP. It's like someone responding to the suggestion to "use strong/unique passwords" with "but what if I don't have any authentication?"

brettdong 10y ago

Completely agree. There are forks, mirrors and crawlers on GitHub, even you rewrite the commit and force push to GitHub server, the original commit data still exists in the forks and mirrors, and in fact anyone can even view the original commit in your own repo if they know its commit hash.

chmike 10y ago

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.

shimo5037 10y ago
It can be slightly more complex than that if you use a package manager to publish your work. I once accidentally leaked a password due to having both a .gitignore and an .npmignore, and forgetting to include my .env file in the latter. Fortunately, I realized what had happened almost immediately and was able to change the password. Now I tend to `tar tf` everything before publishing.
- gkya 10y ago
  I believe that it's better to not have that kind of sensitive files be dotfiles.
- matt_kantor 10y ago
  Because of issues like this I tend to set up my deploy scripts to first `git clone` into a temporary directory, then do the rest of the work from there.
lloydde 10y ago
Or environmental variables loaded at provisioning though this just moves the target. But these options do not themselves have the "in motion" characteristics that provide the best reliability, scalability and security. If your needs are more sophisticated this means keyservers where hardware security module (HSM) might by part of the equation.
the_af 10y ago
Agreed that you absolutely cannot store sensitive passwords in your source code repo. Your proposed solution, however, has its own share of problems for some deployment scenarios. Where do you get this file from? Assuming you are meant to place it by hand each time you deploy your application... what about autoscaling? What if you want unattended deployment of apps?

lholden 10y ago

Very much this. The first thing you should be doing is making the password useless by changing it. Doing anything else is entirely irresponsible. Sure, remove the file in question after that... but you can't treat the old password as anything other than public knowledge at that point.

muyuu 10y ago

Reminds me of the Bitcoinica fiasco. Stuff happens, especially under pressure. But yeah, if that happens to you, there is no more reasonable course of action than changing it right away.