6

I am wondering about whether it is acceptable (security-wise) to have database login credentials (user/pass) set in an environment variable or passed in as a command-line parameter?

Both of these methods seem risky to me as perhaps others can read the environment variable or read the running processes/history and credentials would be there in plain-text (Is my understanding correct here?)

What would be an acceptable way to do this login? It would be run in a script as part of an automated job/process.

Edit: This is an Oracle database (11g)

Edit #2: Oracle Wallet was considered at one point, but can't be used yet where I work.

user1766760
  • 525
  • 6
  • 13
  • 3
    Your understanding is correct. You should never put your login credentials in plain text. A user with malicious intent can obtain them from a _compiled binary_, let alone a plaintext script. You should check to see if your database application allows password-less login using private keys. – Joseph R. Aug 23 '13 at 18:27
  • 1
    It appears that [Oracle Wallet](http://docs.oracle.com/cd/E11882_01/network.112/e40393/asowalet.htm#autoId0) provides for the ultimate end of plaintext db authentication passwords (yay!). – msw Aug 23 '13 at 18:43

4 Answers4

2

I'm not really experienced with Oracle databases (or databases for that matter), but it seems a Perl solution is possible with Oracle wallet as shown here (Google search terms "oracle database passwordless login").

Joseph R.
  • 38,849
  • 7
  • 107
  • 143
1

Best practices dictate that you should not store passwords in plaintext on disk or in memory. Environment variables are problematic as well. Imagine if a production system was running a monitoring program that does "ps auxwwe" periodically and writes the output to a log file. Your sqlplus credentials would inadvertently be written to the monitor logs, which may be world readable. The more common scenario would be that the logs are shipped to Splunk/ElasticSearch/Hadoop/Loggly.

I wrote a program that communicates credentials securely via file streams here: https://github.com/ryanchapman/safe_sqlplus

Once the credentials have been sent to the sqlplus program, safe_sqlplus zeroes the portion of memory were they were stored.

Ryan A. Chapman
  • 11
  • 1
1

Command line parameters can be read by anyone via /proc/<pid>/cmdline. For processes that exit immediately they can still be shown to someone who uses a ps-like monitoring program.

Passwords in memory on the other hand shouldn't be the problem. Memory can not accessed without superuser rights, and a secure software usually overwrites passwords in memory before freeing it to other processes.

The most common way is to use file permissions. The password goes into a file that can only read by whoever is supposed to be able to. Thus the credentials as a file (be it a key or password) are safe from the common cmdline leaks.

frostschutz
  • 47,228
  • 5
  • 112
  • 159
  • 2
    `/proc//environ` is set 400 (read-only by owner). I doubt there is any *legitimate* means of directly reading someone else's env variables, so that method is probably *more secure* than putting it in a file. – goldilocks Aug 23 '13 at 19:00
  • Whoops, must've had the wrong pid when testing then. :) Thanks for the correction. Might be passed on to child processes though... which a database probably doesn't have. – frostschutz Aug 23 '13 at 19:02
  • @goldilocks I'm a little confused... can you expand on why using an env variable could be more secure? If I want to learn more about this topic, how would I phrase that (say in a Google search)? – user1766760 Aug 23 '13 at 19:32
  • @user1766760 : One reason would be that with the file, the password is permanently stored somewhere (and I guess in plain text!). If someone gets physical access to the system (e.g., steals your laptop), file permissions won't save you. With the env variable, it's only in memory when needed *and* it's "scoped", by which I mean it's only visible to the subshells to which it has been `export`ed. If you are going to set things like that from the command-line, *don't keep a permanent `.bash_history`,* or else your password will end up in plain text in a disk file... – goldilocks Aug 23 '13 at 19:41
  • Which env variable is it anyway? `cmd $VAR` is command line again, so that's useless. It'd have to be supported by the client in question. Also at least according to http://dev.mysql.com/doc/refman/5.0/en/password-security-user.html environment variables aren't considered secure either. – frostschutz Aug 23 '13 at 19:47
1

You need to separate the command line that opens your DB client and the passwd submission. Of course, different RDBMSs/clients will work differently. Here is an example for sqlplus (default ORCL command line utility):

sqlplus /nolog<<!!

connect $USER/$PASSWD@$SID;

...
--some SQL
...

!!

if you do that, ps will not show the passwd in the list of processes.

amphibient
  • 12,222
  • 18
  • 62
  • 87
  • This is the same answer that you gave on this question: http://stackoverflow.com/a/13478804/33204, so I'd characterize it the same way as @DavidAldridge did on that stackoverflow Q and state that this isn't a good way to hide your passwords. Most enterprises strictly forbid doing it this way. – slm Aug 23 '13 at 21:05