On Wednesday, 09/02/2009 at 07:02 EDT, Scott Rohling
<[email protected]> wrote:
> Just fyi - You can use the NETRC DATA file to store userid/pw for
different
> hosts... that way at least you're not hardcoding that part in an
EXEC. If
> it's present -- you can assume you will be logged in when you start FTP
-- so
> you just queue up the commands you want issued, and skip the USER part..
Ahem. That means you have a host password laying around in cleartext on a
disk, likely in violation of your company's password security policy.
"Hates it....."
If you need to do this sort of thing, at least obscure the password with
something like
hashpw = bitxor(pw, copies('AA'x, length(pw)) )
and store it on disk with name other than "HASHED PASSWORD". Issue the
same function against the hashed version gives you the original password.
Stack it rather than putting it in NETRC DATA.
Or, for something a little safer, have your PROFILE EXEC prompt you for
your password, hash it, and put it in an in-memory-only GLOBALV variable.
Your exec retrieves the variable and reverses the hash. (Please name it
something other than MYPASSWORD.)
For extra credit you can get creative with the CIPHER MESSAGE (KM)
instruction and the use of a prompted-for "master key" to decipher each
line of a file. Therein you will find the list of hosts and passwords
that you previously encrypted with said master key. Again, store the
array GLOBALV PUT (not PUTS or PUTP). GLOBALV GET the one you want. The
password file remains securely encrypted and your hands never leave your
arms at any time during the show.
The extra paranoid among us will still apply the bitxor hash to the
password before storing in GLOBALV. Doing so ensures that it doesn't
appear in a dump in cleartext. Of course, if someone looks at memory
while your "ftp" exec is running, they will see the password. It has to
come out of hiding at some point...
Alan Altmark
z/VM Development
IBM Endicott
