5 ms·

Every production product I’ve ever worked on, the entire team put database credentials in the environment variables.

by hellofunk 6y ago

_wldu 6y ago
It's way better than hard coding them into the code.
- willis936 6y ago
  Why is that? Also, as an aside: The very premise of plaintext credentials for computer-computer database connections always seemed strange to me. Maybe I'm just not knowledgeable enough here, but I wish the standard for database credentials was key-based.
  - ebg13 6y ago
    > Why is that? You don't want to accidentally commit your credentials to github and have the world see them. At least if they're in ENV they stay private as long as your environment does.
    - chrisfinazzo 6y ago
      What about the global .gitconfig? One of the basic key value pairs is the GPG signingkey, which is usually stored in cleartext in the aforementioned file. Although the credential.helper is in my Keychain (iCloud-backed 2FA) In theory someone could copy this and try to sign commits as me, but I have to think this value is unique and they would get rejected if they tried to use it. My login credentials are 2FA as well, at least on unknown machines, so they would be prompted there as well. Personal Access Tokens for the CLI would be another way to prevent nefarious things from happening.
  - mberning 6y ago
    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.
  - bpfrh 6y ago
    Because if I give an external developer access to the source code for developing, I won't expose internal data and systems. Bigger companies also may have different compliance restrictions which means developers don't get access to production, only the Administrators.
  - auspex 6y ago
    if you hard code the credentials you can’t tumble them without a complete rebuild. Also, and more importantly if you check in your code those creds are now in source control and should be considered compromised. Injecting via secrets allows us to tightly control where the secret goes and who has access as well as make it easy to tumble.
  - tnorthcutt 6y ago
    If you put secrets in your codebase, they're now on x machines, where x is the number of developers on your team, plus their old laptops they gave away to family members and forgot to wipe, plus Backblaze because one developer doesn't have git repositories excluded from their backup settings, plus GitHub because that's where your repo is hosted. If you don't store secrets in your codebase, they're just on ~one machine: the server hosting your application.
    - jfengel 6y ago
      Every server hosting your application. Things get trickier as systems scale.
  - laumars 6y ago
    Lots of reasons: - passwords would end up in version control repositories. A whole article could be written on this point alone but to summarise: those credentials will then be in your projects history forever more (or until nuking the history becomes more important than keeping the history) - you can’t then change the credentials easily without having to push a new version of the application - you expose the password to developers, which might be fine in smaller teams but larger organisations might separate those duties. You might also bring in contractors who you wouldn’t trust with DB access or shouldn’t have access for data compliance reasons - you make it harder to have different credentials for different environments (Eg dev, UAT, staging and production). There is no workaround for that doesn’t introduce other problems....aside from removing hardcoded passwords.
    - vharuck 6y ago
      >those credentials will then be in your projects history forever more (or until nuking the history becomes more important than keeping the history) With Git, it's not "nuking" so much as "retroactively creating a different timeline in which the secret wasn't shared." Still a pain in the ass if there's more than one developer.
    - gregoriol 6y ago
      Well, 2/ you probably can't change the credentials just by changing the ENV anyway: there will likely be some kind of restart/reload to perform on one or many components (and such actions better be well logged and tracked, which happens with a redeploy) 3/ your production DB shouldn't be accessible directly with the password, otherwise you have a bigger problem 4/ it's not harder, it's just an if/switch away from you (instead of another set of tools) It's good to have secrets managed, like API keys, private keys, ... but most of the time it more of hiding them, which is not sufficient! And as the article says, it is very easy to let them slip through logs/dump, as well as let some code treat them in a insecure (or even malicious) manner.
      - laumars 6y ago
        2. A service restart is always going to be less risky than shipping a new application (which would also require a restart as well). 3. In an ideal world I’d agree with you. However in many places it is and even in places where it’s not, not hardcoding passwords helps provide defence in depth. 4. Harder to do it securely. Your solution leaks all passwords to all environments and is possibly the worst workaround to the problem (I’ve seen CI/CD inject the correct passwords, which seems the best approach but if you’re going to those lengths then you might as well use a secrets management service)
  - time0ut 6y ago
    It is pretty well supported on many common databases. A few years ago, I added short lived, auto-rotated certificates (signed by our internal CA) to all of our applications. We used these for mTLS for internal app to app calls. I also wanted to use them to authenticate to the databases. MySQL and Oracle support this sort of authentication just fine. The obstacle I ran into was trying to explain to the DBAs what a certificate was and why it'd be a good idea to use it instead of having them manage user names and passwords for us. They decided it was too much work and stone walled. I eventually gave up and moved on.
axegon_ 6y ago
This is commonplace for most people when they start working on a new project, including myself. And sometimes when you are rushing through to meet some deadline it slips through and you end up realizing a lot later. In order to tackle this, I've developed the habit of adding a middle layer in the code between the configuration (whether it be ENV variables or config files) and the actual application. So when you eventually have time or realize that you forgot about it, swapping/fixing it isn't an issue.
Minor49er 6y ago
The author's arguments aren't compelling. Most of his points can be solved by properly configuring any logging processes to grab only what's necessary and not letting newbies commit unreviewed code.
- IshKebab 6y ago
  But the author's argument is that people don't do that. You're pretty much saying "The argument for seatbelts is not compelling. The problem can be solved by driving carefully."
  - Minor49er 6y ago
    No, I would be saying that wearing a seatbelt improperly is obviously dangerous and ill-advised.

Every production product I’ve ever worked on, the entire team put database credentials in the environment variables.

_wldu 6y ago

It's way better than hard coding them into the code.

willis936 6y ago
Why is that? Also, as an aside: The very premise of plaintext credentials for computer-computer database connections always seemed strange to me. Maybe I'm just not knowledgeable enough here, but I wish the standard for database credentials was key-based.
- ebg13 6y ago
  > Why is that? You don't want to accidentally commit your credentials to github and have the world see them. At least if they're in ENV they stay private as long as your environment does.
  - chrisfinazzo 6y ago
    What about the global .gitconfig? One of the basic key value pairs is the GPG signingkey, which is usually stored in cleartext in the aforementioned file. Although the credential.helper is in my Keychain (iCloud-backed 2FA) In theory someone could copy this and try to sign commits as me, but I have to think this value is unique and they would get rejected if they tried to use it. My login credentials are 2FA as well, at least on unknown machines, so they would be prompted there as well. Personal Access Tokens for the CLI would be another way to prevent nefarious things from happening.
- mberning 6y ago
  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.
- bpfrh 6y ago
  Because if I give an external developer access to the source code for developing, I won't expose internal data and systems. Bigger companies also may have different compliance restrictions which means developers don't get access to production, only the Administrators.
- auspex 6y ago
  if you hard code the credentials you can’t tumble them without a complete rebuild. Also, and more importantly if you check in your code those creds are now in source control and should be considered compromised. Injecting via secrets allows us to tightly control where the secret goes and who has access as well as make it easy to tumble.
- tnorthcutt 6y ago
  If you put secrets in your codebase, they're now on x machines, where x is the number of developers on your team, plus their old laptops they gave away to family members and forgot to wipe, plus Backblaze because one developer doesn't have git repositories excluded from their backup settings, plus GitHub because that's where your repo is hosted. If you don't store secrets in your codebase, they're just on ~one machine: the server hosting your application.
  - jfengel 6y ago
    Every server hosting your application. Things get trickier as systems scale.
- laumars 6y ago
  Lots of reasons: - passwords would end up in version control repositories. A whole article could be written on this point alone but to summarise: those credentials will then be in your projects history forever more (or until nuking the history becomes more important than keeping the history) - you can’t then change the credentials easily without having to push a new version of the application - you expose the password to developers, which might be fine in smaller teams but larger organisations might separate those duties. You might also bring in contractors who you wouldn’t trust with DB access or shouldn’t have access for data compliance reasons - you make it harder to have different credentials for different environments (Eg dev, UAT, staging and production). There is no workaround for that doesn’t introduce other problems....aside from removing hardcoded passwords.
  - vharuck 6y ago
    >those credentials will then be in your projects history forever more (or until nuking the history becomes more important than keeping the history) With Git, it's not "nuking" so much as "retroactively creating a different timeline in which the secret wasn't shared." Still a pain in the ass if there's more than one developer.
  - gregoriol 6y ago
    Well, 2/ you probably can't change the credentials just by changing the ENV anyway: there will likely be some kind of restart/reload to perform on one or many components (and such actions better be well logged and tracked, which happens with a redeploy) 3/ your production DB shouldn't be accessible directly with the password, otherwise you have a bigger problem 4/ it's not harder, it's just an if/switch away from you (instead of another set of tools) It's good to have secrets managed, like API keys, private keys, ... but most of the time it more of hiding them, which is not sufficient! And as the article says, it is very easy to let them slip through logs/dump, as well as let some code treat them in a insecure (or even malicious) manner.
    - laumars 6y ago
      2. A service restart is always going to be less risky than shipping a new application (which would also require a restart as well). 3. In an ideal world I’d agree with you. However in many places it is and even in places where it’s not, not hardcoding passwords helps provide defence in depth. 4. Harder to do it securely. Your solution leaks all passwords to all environments and is possibly the worst workaround to the problem (I’ve seen CI/CD inject the correct passwords, which seems the best approach but if you’re going to those lengths then you might as well use a secrets management service)
- time0ut 6y ago
  It is pretty well supported on many common databases. A few years ago, I added short lived, auto-rotated certificates (signed by our internal CA) to all of our applications. We used these for mTLS for internal app to app calls. I also wanted to use them to authenticate to the databases. MySQL and Oracle support this sort of authentication just fine. The obstacle I ran into was trying to explain to the DBAs what a certificate was and why it'd be a good idea to use it instead of having them manage user names and passwords for us. They decided it was too much work and stone walled. I eventually gave up and moved on.

axegon_ 6y ago

This is commonplace for most people when they start working on a new project, including myself. And sometimes when you are rushing through to meet some deadline it slips through and you end up realizing a lot later. In order to tackle this, I've developed the habit of adding a middle layer in the code between the configuration (whether it be ENV variables or config files) and the actual application. So when you eventually have time or realize that you forgot about it, swapping/fixing it isn't an issue.

Minor49er 6y ago

The author's arguments aren't compelling. Most of his points can be solved by properly configuring any logging processes to grab only what's necessary and not letting newbies commit unreviewed code.

IshKebab 6y ago
But the author's argument is that people don't do that. You're pretty much saying "The argument for seatbelts is not compelling. The problem can be solved by driving carefully."
- Minor49er 6y ago
  No, I would be saying that wearing a seatbelt improperly is obviously dangerous and ill-advised.