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.

Improve this question
2
  • 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. Commented Aug 23, 2013 at 18:27
  • 1
    It appears that Oracle Wallet provides for the ultimate end of plaintext db authentication passwords (yay!). Commented Aug 23, 2013 at 18:43

4 Answers 4

Reset to default
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").

Improve this answer
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.

Improve this answer
5
  • 2
    /proc/<pid>/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. Commented Aug 23, 2013 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. Commented Aug 23, 2013 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)? Commented Aug 23, 2013 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 exported. 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... Commented Aug 23, 2013 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 dev.mysql.com/doc/refman/5.0/en/password-security-user.html environment variables aren't considered secure either. Commented Aug 23, 2013 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.

Improve this answer
1
  • This is the same answer that you gave on this question: 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. Commented Aug 23, 2013 at 21:05
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.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.