|
Home > Archive > Unix Shell > October 2007 > Ksh password encryption for batch processing
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Ksh password encryption for batch processing
|
|
|
| Can anyone help me come up with a solution for the following scenario?
We have a password file stored in plain text, as read only by the
owner of the file. Normally, that owner reads that password into a
variable, and is used in our batch processing environment to log into
the database. Recent 'rules' have stated that we cannot store
passwords in plain text.
So, even though it's not very powerful encryption, we could always
create an encryption key, make that read only, then encrypt and
decrypt the password with 'crypt'. This might temporarily allow us to
'not break the rules', but isn't that really just passing the buck
down to the encryption key as read only?
The other option is to store the key in the environment variable (for
AIX, it's CrYpTkEy). But not sure what secure method could do that.
Plus, once that key is stored in the owners environment, then we're
back to again, having the information available to anyone who can su /
sesudo to that account. To me, I don't see the point, but the rules
are the rules I suppose.
Any thoughts or advice on similar issues?
Thanks in advance,
Tom
| |
| Janis Papanagnou 2007-10-03, 7:30 am |
| Tom wrote:
> Can anyone help me come up with a solution for the following scenario?
>
> We have a password file stored in plain text, as read only by the
> owner of the file. Normally, that owner reads that password into a
> variable, and is used in our batch processing environment to log into
> the database. Recent 'rules' have stated that we cannot store
> passwords in plain text.
>
> So, even though it's not very powerful encryption, we could always
> create an encryption key, make that read only, then encrypt and
> decrypt the password with 'crypt'. This might temporarily allow us to
> 'not break the rules', but isn't that really just passing the buck
> down to the encryption key as read only?
>
> The other option is to store the key in the environment variable (for
> AIX, it's CrYpTkEy). But not sure what secure method could do that.
> Plus, once that key is stored in the owners environment, then we're
> back to again, having the information available to anyone who can su /
> sesudo to that account. To me, I don't see the point, but the rules
> are the rules I suppose.
>
> Any thoughts or advice on similar issues?
The short answer is; passwords are to be typed interactively, and rules
(security policies) are to prevent passwords lying around visibly. An
application where a key hierarchy (some master key) is appropriate is
if to avoid to memorize a set of different keys. I wouldn't trust in
the "safety" of the OS environment if you're in a critical environment;
you can assume that admins can read every plaintext bit in the computer
as you suspect.
Janis
>
> Thanks in advance,
> Tom
>
| |
|
| What's the preferred method for passwords in a batch environment
then? Where the data processing applications are scheduled, and run
without human intervention? Is there one?
| |
| Bill Marcum 2007-10-03, 1:28 pm |
| On 2007-10-03, Tom <tomsellner@gmail.com> wrote:
> What's the preferred method for passwords in a batch environment
> then? Where the data processing applications are scheduled, and run
> without human intervention? Is there one?
>
Create a user who cannot log in, but can run the application without a
password. Or set the application as that user's login shell, if you
sometimes need to run the application interactively as that user.
| |
|
| I'm not sure I can translate that to a process model of:
get data
log into sqlplus as uid/passwd
so stuff
done
Can you elaborate on the method you're describing as it relates to my
scenario?
Thanks again!
Tom
| |
| Chris F.A. Johnson 2007-10-03, 7:22 pm |
| On 2007-10-03, Tom wrote:
> Can anyone help me come up with a solution for the following scenario?
>
> We have a password file stored in plain text, as read only by the
> owner of the file. Normally, that owner reads that password into a
> variable, and is used in our batch processing environment to log into
> the database. Recent 'rules' have stated that we cannot store
> passwords in plain text.
Yet you are allowed to use the variable containing the clear text
password on the command line, where its contents will be visible
with the ps command? Someone is trying to solve the wrong problem.
--
Chris F.A. Johnson, author <http://cfaj.freeshell.org/shell/>
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
===== My code in this post, if any, assumes the POSIX locale
===== and is released under the GNU General Public Licence
| |
|
| > Yet you are allowed to use the variable containing the clear text
> password on the command line, where its contents will be visible
> with the ps command? Someone is trying to solve the wrong problem.
In this scenario, we're actually calling sqlplus via a unix here doc,
and the password is on the second line, thus does not show up in the
process table. Currently, the password is only visible to the user
who owns the file, and in that users environment variables. However,
since it's still stored as plain text ... it violates, the "rules".
I personally think that encrypting it doesn't really buy us much, but
like I said, someone said we have to do it, so I'm looking for any
advice in doing it in the most secure manner.
Thanks again,
Tom
| |
|
| So I guess no one has any ideas?
| |
| Will Renkel 2007-10-10, 7:35 am |
| tomsellner@gmail.com wrote:
>So I guess no one has any ideas?
>
I dont recall the original question/article
But I do password processing in batch jobs all the time
What I do is store the password in an encrypted file of my own
That is necessary so anyone who views the stored batch job (such as in cron or at processing)
cant see the de-crypted password.
Then in the batch job I de-crypt the password from my stored file
and use expect to pass it over to the new host/login
Hope this helps.
--
---------------------------------------------------------------
Will Renkel
Wheaton, Ill.
---------------------------------------------------------------
| |
|
|
|
|
|