Geek Answers Handbook

Security Strategies for Storing Password on Disk

I am creating a batch job package that requires regular access to a database running on a Solaris 10 machine. Due to (irreversible) design limitations, we need to use a specific program to connect to it. The specified interface requires that we pass a text password on the command line to connect to the database. This is a terrible security practice, but we are stuck with it.

I try to ensure that everything is securely fixed on our side. Since processing is automated (i.e., we cannot request a password), and I cannot store anything outside the disk, I need a strategy to safely store our password.

Here are some basic rules.

  • There are several users in the system.
  • We can assume that our permissions are respected correctly (i.e. if a file with a is chmod'd up to 600, it will not be publicly accessible)
  • I do not mind the superuser access to our saved password.

That's what i still have

  • Save password in password.txt file
  • $ chmod 600 password.txt
  • The process reads with password.txt when it is needed.
  • Buffer rewritten with zeros when it is no longer needed

Although I'm sure there is a better way.

+5
source share
3 answers

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

chmod 400 , . chmod 600 , . , chown'ed , . , . , . , , . SELinux AppArmor - / .

Edit: Shread - , .

: Moron/Mike unix ps aux , . , : wget ftp://user:password@someserver/somefile.ext. CURL. . bash , export HISTFILE=

+4

, . . - . .

- . "ps", , . , , . , . , , . , , , .

, , . script, , script . , . , .

, . , . ,

  • chmod 400 ,
  • ('.') ,
  • , .
  • , - "strings" unix.

, . , "ps" . deadbolt , .

+2

, . , ​​ , , , .

prctl (2) PR_SET_NAME . , , ptrace (2), , , :/

, grsecurity CONFIG_GRKERNSEC_PROC_USER:

"Y", , root, , , .

ps , ps /proc/<pid>/cmdline

The specified interface requires us a text password at the command to connect to the database. This is a terrible security practice, but we are stuck with it.

This is only a bad security practice due to problems in the O / S architecture. Do you expect other users to be able to intercept your system calls? I would not blame the developer who fell into this trap.

0
source

More articles:


All Articles