Currently, I've many scripts that need to log in as superuser to automate many tasks. (For example, creating tables in databases, creating other users, etc.)

Instead of having the credentials (especially the passwords) stored directly in the script, I'm reading them from a file (call it pwds.txt), which can be accessed only by root user.

Some of my colleagues say that a more secure approach is to have the password encrypted in pswds.txt, hide the key somewhere and decrypt the encrypted data in the script before I use it.

I claim that it just reduces the problem into finding where key is located, which doesn't seem hard at all to and adversary that can read the script. I think that this process just complicates the programming without actually providing any real layer of protection.

Two questions:

  1. Who is more correct, me or them? (and why)
  2. I know that 100% security doesn't exist, but what are the best practices for my problem?
  • 2
    um, the file can be accessed only by root user, and you need to access the file in order to know the root password (which is needed to access the file)... how's that working out for you?
    – NH.
    Feb 21, 2018 at 20:48
  • the root password isn't written there, only password for different superusers. The idea, for example for installation scripts, is to log in (manually) to root, and then run the script. (which can now read the password, say, for database administrative account)
    – sel
    Feb 21, 2018 at 20:52
  • or you could just simplify the whole process, don't store passwords insecurely anywhere, and simply give the root user DB permissions (surprised if they don't already), and run the script as root (that way you enter the password rather than storing it).
    – NH.
    Feb 21, 2018 at 20:53
  • I found this useful: medium.com/@jp9573/…
    – Jay Patel
    Feb 22, 2020 at 8:29

1 Answer 1


1) You are 100% correct, Why? If machine gets compromised the attacker will be still able to retrieve the decryption key as it's necessary to be symmetric encryption to decrypt by app and the key file has to have same read permissions as the app so the app can read it.

I mean app still needs to have hardcoded secret decrypt key directory in it so attacker just looks for it :D , even if app is an binary executable attacker can easily dump strings of file directories and files from it.

I know because I did it from an Go language program that I needed to debug and I didn't have source code (one of clients app hosted on server) :)

Buffer overflow and so on attacks will function if hole is present as app ether ways stores data in memory to reuse for example for database auth.

2) The best solution is to have a central vault where each app requests its secrets and leases them. One solution of this kind is https://www.vaultproject.io/ and more details on it https://www.vaultproject.io/docs/internals/architecture.html

Best general practice is to minimise access and control rights of each role for each app resource. Example: If an app just uses one database don't give that user rights to view other or to execute DML on others, remove drop table rights if the app doesn't do migrations, and so on.

If you don't use vault if script is executed by example root user don't store secrets with ownership of less privileged users. Let the owner be the same user, use read, write, execute permissions only what you really need.

Use TLS when you can for your resources as one tcp dump leaks data if attacker manages to get the auth phase however you store the secret data.

  • I agree the vault approach is the best. Note you may find application-specific vaults, e.g. for databases. It also seems some vault-type solutions work on the hardware level. see oracle.com/technetwork/database/options/key-management/overview/…
    – 3pitt
    Sep 18, 2019 at 13:54
  • 3
    What's the point of the vault when it comes to the secrets? Isn't this just substituting DB auth with Vault auth? If an attacker can read the Vault credentials it can request a new/the secret and access the DB. vaults are useful as a management tool (avoiding deploying the same secret across multiple servers) but I'm not sure they actually do anything as a security tool. This is just equivalent to storing the password encrypted in the configuration file, AFAIK. Jul 7, 2020 at 17:22
  • I agree with Margaret. Forcing the password rotation policy (or related) is much stronger when considering security. However the question was about storing only, and for this narrow aspect, just considering encryption is enough. Jul 14, 2020 at 16:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .