topic Secure password verification script in Operating System - HP-UX

Secure password verification script

Kevin Moore_2 — Thu, 27 Sep 2001 13:59:16 GMT

Hi,
I have a bit of a tricky problem. Our application support people have lots of scripts where they have hardcoded the application username and password. This creates a problem of me as sys admin, when I want to change this password.
I am looking for a way, where the script can lookup the password, so only one file would have to be changed for future password changes. This file also needs to be secure from all users.
I was looking at using grep, and having the file in a directory which only has execute rights. This hides the file, but once anyone knows the filename (which will have to be in the scripts) they will be able to read it.
I would greatly appreciate any help or suggestions on this (what about a secure database for example)

Thanks,
Kevin

Re: Secure password verification script

James R. Ferguson — Thu, 27 Sep 2001 14:16:29 GMT

Hi Kevin:

If we place security aside for the moment, a general guideline for managing global variables is to place them in *one* file which is sourced (included) as needed. For scripts, you do this like by specifying a "dot" a "space" and the filename, as:

#!/usr/bin/sh
cd $HOME
. ./myfile #...source $HOME/myfile

Regards!

...JRF...

Re: Secure password verification script

David Lodge — Fri, 05 Oct 2001 14:14:23 GMT

This all depends on what you're doing with the passwords and how they're been used.

If you want to do password look ups, you can use:
* blank textfile (but anybody who can run the script can see this - ergo only run scripts as special users which normal users don't have the passwords for)
* Database using OS authentication (bit overkill really!)
* Some proprietry progrsm to keep an encrypted filebase of user/passname/machine combinations and to authenticate and decrypt on current user.

All 3 of the above have their problems, all 3 are a pain to admin and all 3 could potentially show an account user/password to a simple 'ps' list.

A much better solution is to analyse how you're using your passwords. In general use passwords don't *need* to be used, you can:
* Passwords to databases: Use OS authentication, eg on oracle use OPS$ accounts.
* Passwords for file transfer: Use scp instead of ftp - this also stops cleartext passwords flying across the networks
* Spawning scripts as different users - use some creative scheduling to call the scripts from root's cron, or use a package which allows jobs tied together (eg Maestro, Control M)

My suggestion is to get your developers to defend *every* use of a cleartext password within a shell script/config file.

dave