Home/ Questions/Q 799041
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-14T23:03:52+00:00

I am building a suite of batch jobs that require regular access to a

  • 0

I am building a suite of batch jobs that require regular access to a database, running on a Solaris 10 machine. Because of (unchangable) design constraints, we are required use a certain program to connect to it. Said interface requires us to pass a plain-text password over a command line to connect to the database. This is a terrible security practice, but we are stuck with it.

I am trying to make sure things are properly secured on our end. Since the processing is automated (ie, we can’t prompt for a password), and I can’t store anything outside the disk, I need a strategy for storing our password securely.

Here are some basic rules

  1. The system has multiple users.
  2. We can assume that our permissions are properly enforced (ie, if a file with a is chmod’d to 600, it won’t be publically readable)
  3. I don’t mind anyone with superuser access looking at our stored password

Here is what i’ve got so far

  • Store password in password.txt
  • $chmod 600 password.txt
  • Process reads from password.txt when it’s needed
  • Buffer overwritten with zeros when it’s no longer needed

Although I’m sure there is a better way.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    This is not a solution for cryptography. No matter the cipher used, the key will be equally accessible to the attacker. Cyrpto doesn’t solve all problems.

    chmod 400 is best, this makes it read only. chmod 600 is read write, which may or may not be a requirement. Also make sure its chown’ed by the the process that needs it. This is really the best you can do. Even if you are sharing the machine with other users they shouldn’t be able to access it. Hopefully this is a dedicated machine, in that case there isn’t much of a threat. SELinux or AppArmor will help harden the system from cross process/cross user attacks.

    Edit:
    shred is the tool you need to securely delete files.

    Edit: Based on Moron/Mike’s comments the unix command ps aux will display all running processes and the command used to invoke them. For instance the following command will be exposed to all users on the system: wget ftp://user:password@someserver/somefile.ext. A secure alternative is to use the CURL library. You should also disable your shells history. In bash you can do this by setting an environment variable export HISTFILE=

    • 0