3 ms·

Now every developer has access to any db credential that was in source control. If your project has had hundreds or thousands of developers that is a security c

Now every developer has access to any db credential that was in source control. If your project has had hundreds or thousands of developers that is a security concern.

gregoriol 6y ago
If your database is accessible by everyone, then this is your security concern.
- imtringued 6y ago
  Surely you are missing the point on purpose aren't you? Authorization happens through secrets because it is trivial to spoof anything that is not a secret. If you have a party where only known celebrities are allowed to attend then I can just send a double. That same logic applies to two independent servers and creating a server that is mirroring another is much easier than finding a double. The only way to distinguish between a fake and the original is by looking at things the original doesn't share publicly because the double cannot replicate things it doesn't know. Ok, I hope this explanation was good enough to make you understand that authorization should be based on secrets because they cannot be replicated while kept secret. So "if your database is accessible by everyone" then it must be because the secret is accessible to everyone. However, this is where you start to contradict yourself. You suggested that delivery of the secret is not a problem because "3/ your production DB shouldn't be accessible directly with the password, otherwise you have a bigger problem". As we have established, anything that isn't a secret can be replicated and therefore should never be relied upon. If you store passwords to your database in the source code it's likely that you are also storing other secrets such AWS keys or the password for the firewall dashboard in an accessible repository. Now an attacker is behind your firewall and can access the database anyway. I don't understand why you seem to defend storing passwords in source code by arguing about an irrelevant detail. Even if you are completely uninterested in securing your application you would still store the passwords outside of the source code simply for convenience. When you have a production, staging and development environment then each environment will need a different password. The logical conclusion would be to make the password configurable just for this alone. 90% of the features that something like Vault provides are actually more about convenience and password management than actually increasing security. Most of the security benefits come from the fact that it encourages responsible handling of passwords, not from the fact that the software itself is more secure.

Now every developer has access to any db credential that was in source control. If your project has had hundreds or thousands of developers that is a security concern.

gregoriol 6y ago

If your database is accessible by everyone, then this is your security concern.

imtringued 6y ago
Surely you are missing the point on purpose aren't you? Authorization happens through secrets because it is trivial to spoof anything that is not a secret. If you have a party where only known celebrities are allowed to attend then I can just send a double. That same logic applies to two independent servers and creating a server that is mirroring another is much easier than finding a double. The only way to distinguish between a fake and the original is by looking at things the original doesn't share publicly because the double cannot replicate things it doesn't know. Ok, I hope this explanation was good enough to make you understand that authorization should be based on secrets because they cannot be replicated while kept secret. So "if your database is accessible by everyone" then it must be because the secret is accessible to everyone. However, this is where you start to contradict yourself. You suggested that delivery of the secret is not a problem because "3/ your production DB shouldn't be accessible directly with the password, otherwise you have a bigger problem". As we have established, anything that isn't a secret can be replicated and therefore should never be relied upon. If you store passwords to your database in the source code it's likely that you are also storing other secrets such AWS keys or the password for the firewall dashboard in an accessible repository. Now an attacker is behind your firewall and can access the database anyway. I don't understand why you seem to defend storing passwords in source code by arguing about an irrelevant detail. Even if you are completely uninterested in securing your application you would still store the passwords outside of the source code simply for convenience. When you have a production, staging and development environment then each environment will need a different password. The logical conclusion would be to make the password configurable just for this alone. 90% of the features that something like Vault provides are actually more about convenience and password management than actually increasing security. Most of the security benefits come from the fact that it encourages responsible handling of passwords, not from the fact that the software itself is more secure.