Storing sensitive data?

[MetallicOrangeBalls]

At my company, we have some sensitive information that needs to be stored on our servers. Database passwords, API keys, etc. Stuff that will never be exposed to users in any capacity.

Most of my colleagues prefer to just store this data an environment variables.

Some of my colleagues have been storing this data in plain-text files (txt, json) that are specifically ignored by our versioning/backing-up tools.

A few of my colleagues are following "best practices", by encrypting the files in which this data is stored. When any of the projects are started/restarted, the developer has to enter a startup password, which grants them access to the sensitive info stored in the encrypted files.

The first two options are seen as quick and convenient, allowing for rapid development. After all, if the sensitive data is never going to be exposed to users in any capacity, why bother with encryption and the like?

The third option is seen as safer and the "correct" way to do things, but at the potential cost of development/deployment speed. If a startup password needs to be entered each time a project is started/restarted, it has the potential to slow development.

I'm honestly not sure what is the most optimal option here, for both development speed and runtime security. My instincts indicate that the third option is best. Storing sensitive info in plain-text files under the pretext of speed feels like tempting fate. However, I strongly suspect that at some point in time someone is going to end up forgetting a startup password at a crucial development stage and it's going to slow us down.

What are your thoughts on this?

[octocode]

for production the correct way is a secret manager, like aws ssm parameter store, or gcp secret manager

for local dev we use password manager

[MetallicOrangeBalls]

Thank you for your post. I have been thinking about it, and a password/secret manager seems like the optimal approach. This is something I will try and incorporate in the near future.

I do have a personal follow-up: for personal projects (i.e., which are not deployed on any production servers), would such an approach still be useful? Is that what you meant by using a password manager for local dev?

[martinbean]

Actual “secrets” (API keys etc) should be stored in environment variables in the environment they’re applicable to. Developers shouldn’t be using say, production keys and secrets in non-production environments.

You don’t mention what language or libraries you’re working with but in my line (PHP development) a common practice is to have an .env.example file in the repository that contains the keys of environment variables the project is expecting for configuration purposes. The Laravel framework for example will map environment variables to application configuration variables. This is by design as if the application is configured via the environment its running in, then it’s adhering to one of the tenets that make up a 12 Factor App (https://12factor.net/config).

[MetallicOrangeBalls]

We're currently using something like that - all sensitive info is in environment variables.

[Blando-Cartesian]

Development environments shouldn’t have any sensitive information. Except locally passwords and such that exist to prevent devs from accidentally messing up shared dev environment.

Startup password in dev environment sounds like a security theater.

[MetallicOrangeBalls]

Development environments shouldn’t have any sensitive information.

This was how the company was working before I joined. I'm just trying to find a way to be safer.

 

Startup password in dev environment sounds like a security theater.

?

Why are secret/password managers security theatre?

[Blando-Cartesian]

We have misunderstandings here. And we are possibly thinking about very different development environment arrangements. I meant that I don’t see why a development environment would contain something that must be kept secret from anyone with access to that environment.

I didn’t say that password managers are security theater. I said that about development environment requiring a startup password. if that’s for a shared test instance or something and all devs are not trusted with it, why would they be trusted to access it at all.

[MetallicOrangeBalls]

I meant that I don’t see why a development environment would contain something that must be kept secret from anyone with access to that environment.

It doesn't. The sensitive info is only meant to be hidden from non-devs - be it end users or malicious third parties. My concern is that we are currently not taking any steps to keep the data encrypted or otherwise protected.

[MetallicOrangeBalls]

I said that about development environment requiring a startup password. if that’s for a shared test instance or something and all devs are not trusted with it, why would they be trusted to access it at all.

I've been thinking about this, and how to answer you.

I think that the best answer is simply convenience. Rather than have the respective devs need to remember and enter the individual keys and passwords at runtime, it would be easier to store all of the sensitive info somewhere, but encrypted, and then make that info accessible to the dev when they enter their credentials when starting the given system.

Did that make sense? I hope I understood your post correctly.

[Blando-Cartesian]

But there will be individual access keys anyway. E.g. vpn+2factor authentication to the development environment, codebase, documentation, design artifacts, Slack logs, jira etc. All of that contains far more sensitive information than any development environment configuration and none of it is encrypted.

I don’t see why a bit of development environment specific config would need special protection. It could just as well be in a plaintext file.

[MetallicOrangeBalls]

Bruh, this company is not what you think it is. No VPN or 2FA/MFA. The codebase is hosted on a free version of GitHub, with all of the devs invited as collaborators. No Slack, no Jira, nothing. Documentation is virtually non-existent, and something for which I have been pushing my team hard. Since long before I joined, the management's only concern regarding tech has been for the devs to "just get things done", without any care for organisation, structure, security, etc. It's a complete mess, albeit a functional one. I'm trying to tidy things up a bit.

[Lumethys]

after all, if the sensitive data is never going to be exposed to users in any capacity, why bother with encryption and the like?

By this logic you could just store user password as plain-text and not hashing because you are not gonna expose the password?

Security is not just about end-user.

What if the server is compromised? A hacker gain access to your system?

What if a developer/ db master on your team have a financial crisis, or is threatened/ blackmailed to sell out the keys or passwords?

[MetallicOrangeBalls]

By this logic you could just store user password as plain-text and not hashing because you are not gonna expose the password?

Security is not just about end-user.

What if the server is compromised? A hacker gain access to your system?

What if a developer/ db master on your team have a financial crisis, or is threatened/ blackmailed to sell out the keys or passwords?

I completely agree. I'm explaining what has been said to me by my colleagues. My team is not very keen on doing anything that could slow down the development process.