Old topic I'm thinking about again, wondering about modern best practice ideas... As I'm sure most of you do, we don't store user passwords in the db, just a hash of it and an autogenerated salt value that we also store for each user. But in some situations we need to supply credentials to another system, so those we do have to store in the db, in a file, or hardcode. We can encrypt them, but in a sense that just pushes the question up a layer, because the encryption key has to be stored in the db, in a file, or hard coded. Doing that makes that one master key an extremely vulnerable high value asset, because it gets you access to every password stored with it. How do folks deal with this sort of requirement?

I've used AWS Secrets Manager in the past. I encrypt (by way of the application) what's stored in AWS and limit access by IP. At least, this way, the key and credentials aren't in the same place and are requested and authorized when needed.

Same as what Adam said ^^. Also check out Hashicorp’s free Vault which does the same for storing secrets etc. You can run your own instance of vault.

Any thoughts about getting out of the password game all-together? Using an oAuth system when and where possible helps reduce that security footprint. Standing up your own instance of KeyCloak isn't hard and added bonus of being able to allow users to federate with other systems.

I suggest always using One-time passwords. This way, no matter what method you use to securely write down your passwords digitally, you still require secondary validation. You can time it out, check it for each session, geo-fence it, so on and so forth to "secure" your digital "stuff"

Sort of out of the scope but not irrelevant info but he needs a way of basically storing keys/passwords used by other applications programmatically and not having them hardcoded. So a tool like Vault.

Far as I can see, that just pushes the high value secret, the vault key, into an environment variable. Is that more secure than in the db or code or a file? DB access is subject to network and credentials constraints, as is access to code files or a non-code file. I'm not totally clear on what access to environment vars requires from a hacker perspective. As a human user, you have to be logged into the machine, which you'd have to be to read code or other files too. The environment var I think needs admin access, not positive. I don't know if there are remote APIs to read them. In any case, if you can read the env var you can read the key from the vault, so you could just put the pw in the env var directly. • You wouldn't get the lifecycle features of Vault, but I don't think we need them • You could only read it from that one machine, which isn't enough for us ◦ Put differently, you'd need to set the env var on any machine that needed access ◦ But you'd also need to set the Vault key on each machine ◦ So storing the actual pw in env vars on each machine would only mean extra work when you needed to change it, but it would mean that then

@Dave Merrill Sure but your env variables should not be stored in a DB or saved in code. Should use them in your deployment process where the ${secretvariable} gets replaced in your .env file from somewhere in your deployment process whether thats the vault etc. And yes your point about the key to access the vault, just store them in 2 separate places then. Typically if using AWS, I use KSM or other HSM tools. But the primary approach should be storing everything in your secrets manager tool in your CI/CD

For the best security, we can't comment on how we do it. 😉 Sorry!

@Dave Merrill -- Both passwords in a file(s) or in (DB) are only as secure as your weakest point in security. From a file perspective, how can they read the file to see your login and password information? What happens if your app server crashes, but the front-end proxy continues to run and shows your code in plain text? From a Database perspective, is the connection to the database secure? What mechanisms exist to understand if your database has been accessed without authorization. -- From a use case perspective, if you have a Windows environment and all your servers are part of an AD, use AD authentication to centralize your credentials. If its mostly Unix / Linux, look at Open Directory Server (LDAP)) + many security modules available, including pam/curbs, extra, and other databases, also have plugins. However, I strongly suggest you look at this :: https://openziti.io/docs/learn/introduction/

Also, with the comment about the environment variables -- if the attacker already has enough access to see your root environment variables, game over for that machine. It won't matter if you use a password vault, environment variables, etc., they have access to your system and everything your system touches. End of story. Hard coding ANY creds in code should be considered bad practice these days. You should also be very careful as to what permissions you give the particular db login to the system (this is old hat). Be very precise to the tables/db and separate concerns as much as possible. Control write and global access as much as possible when building your code.

If we're concerned about secrets in code, that must be about scenarios where an intruder can read the code, meaning they're on the server. Yes that means the server itself is compromised, but then the concern is to prevent them bootstrapping their way into other servers, applications, accounts, services, sites, etc. A vault that's keyed by IP does that somewhat, but IPs are spoofable too.

Its about control a clean code base, for example you hire Joe Schmoe who works for you for years, then is laid off, oh no what keys and secrets does he have from our code base and where all are those keys utilized?! Or just store them in a vault where they can be rotated on a regular basis to keep things more secure. And that is just one general scenario. Follow modern best practices

I think I worked with Joe.

it is true that in code they're easily copied, maliciously or not and may end up in places you don't expect or don't realize, so I get it.

So whats the outstanding question then?

Just that the keys to the vault are another layer of secret that has to live somewhere apps can read them.

In OpSec, one of the first things people go for is code. It is on the easier scale to break a web server or java container to spit out a chunk of source code (think of a CF error -- and hope that they get the lines that have the keys in it). Also, another heavily targeted area is source control. People poorly securing their git/svn/gitlab/github/bitbucket repos. Or even worse, source code left on unsecured or poorly secured dev machines. Or equally bad, dev/test/qa setups that are poorly secured (these are often high-value, since devs tend to turn off most front-line and back-line security). If you bake in API keys, tokens, etc. that may be in your production code, that is ripe for the taking.