Looks like a lot of people read Hacker News... https://github.com/doutchnugget/awesomevim/commit/a7292962ce...
GitHub commit search: “remove password”
231–240 of 266 posts
Re: GitHub commit search: “remove password”
#232Seems this goes back to 1989 :)
https://github.com/weiss/original-bsd/commit/0e1066151c90a80...
Re: GitHub commit search: “remove password”
#233Earlier 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…
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.
Re: GitHub commit search: “remove password”
#234Earlier 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…
Somehow I doubt Azure Key Vault is easier than a gitignore line and a text file
Probably not, but it's a lot easier to accidentally commit (or otherwise expose) a text file.
Re: GitHub commit search: “remove password”
#235Earlier quoted context omitted.
And when someone new thinks "that password's wrong, it'll update it!"? Do both, gets rid of the issue on both sides and really doesn't take long :)
Why would they if the tip does not have any passwords in it? It's not like a potential contributor will search the commit log to see if there were once passwords around. Besides, making such changes in public changesets is rude, to say the least.
What I mean is, lots of folks seem to be saying to ignore the presence of the file and just change the password where it's used.
Removing the file, or the password and adding a comment, as well as changing the password where it's used is much less likely to end up with a re-added password later.
Of course, removing the file, adding it to .gitignore and changing the password makes it even harder as a contributor would have to work to add the password back, which is even less likely to happen.
Re: GitHub commit search: “remove password”
#236Earlier quoted context omitted.
Why would they if the tip does not have any passwords in it? It's not like a potential contributor will search the commit log to see if there were once passwords around. Besides, making such changes in public changesets is rude, to say the least.
What I mean is, lots of folks seem to be saying to ignore the presence of the file and just change the password where it's used. Removing the file, or the password and adding a comment, as well as changing the password where it's used is much less likely to end up with a re-added password later. Of course, removing the file, adding it to .gitignore and changing the password makes it even harder as a contributor would…
Oh sorry I tought you were saying to remove it from VCS history (as said many times in the thread). I totally agree you.
Re: GitHub commit search: “remove password”
#237Earlier quoted context omitted.
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.
Shamless plug: SecureStore, our .NET secrets manager: https://neosmart.net/blog/2017/securestore-a-net-secrets-man... 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 run…
What hashing algorithms are you using? Are you updating that hashing algorithms as cipher-suites are being broken? Are we as a user required to set a random seed? Just because it is encrypted doesn't mean it is impossible to decrypt. Especially if default settings in the hash are being used and someone uses a poor password found in another breach. Its a great idea, but I would still worry about security issues around publishing a password hash.
Re: GitHub commit search: “remove password”
#238I liked this one: https://github.com/squared-one/omniauth-unsplash/commit/072b... "... It's not really removing any password, is it? But hey, why not use the momentum ... wheeeeeeeeeeeeeeeeee!"
Another less 'relevant' result: - acceptHandshake = params.pass == PASSWORD + acceptHandshake = true//params.pass == PASSWORD
That just seems like a guy testing his authorization code. I would expect the next commit to put it back to its functional state.
Re: GitHub commit search: “remove password”
#239Earlier quoted context omitted.
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 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.
Re: GitHub commit search: “remove password”
#240Earlier quoted context omitted.
Another less 'relevant' result: - acceptHandshake = params.pass == PASSWORD + acceptHandshake = true//params.pass == PASSWORD
That just seems like a guy testing his authorization code. I would expect the next commit to put it back to its functional state.
Like 'Revert "remove password"'? ;-)