在shell / Perl脚本中保存密码的最佳做法？

Question

I've recently had to dust off my Perl and shell script skills to help out some colleagues. The colleagues in question have been tasked with providing some reports from an internal application with a large Oracle database backend, and they simply don't have the skills to do this. While some might question whether I have those skills either (grin), apparently enough people think I do to mean I can't weasel out of it.

So to my question - in order to extract the reports from the database, my script is obviously having to connect and run queries. I haven't thus far managed to come up with a good solution for where to store the username and password for the database so it is currently being stored as plaintext in the script.

Is there a good solution for this that someone else has already written, perhaps as a CPAN module? Or is there something else that's better to do - like keep the user / password combo in a completely separate file that's hidden away somewhere else on the filesystem? Or should I be keeping them trivially encrypted to just avoid them being pulled out of my scripts with a system-wide grep?

Edit: The Oracle database sits on an HP-UX server.
The Application server (running the shell scripts) is Solaris.
Setting the scripts to be owned by just me is a no-go, they have to be owned by a service account that multiple support personnel have access to.
The scripts are intended to be run as cron jobs.
I'd love to go with public-key authentication, but am unaware of methods to make that work with Oracle - if there is such a method - enlighten me!

Answer 1

Best practice, IMHO, would be to NOT hold any passwords in a shell / Perl script. That is what public key authentication is for.

Answer 2

If the script is running remotely from the server.

1. Make your reports views
2. Give the user you are logging into ONLY access to select on the report views
3. Just store the password.

That way, all that the user can do, is select the data for its report. Even if someone happened to get the password, they would be limited as to what they could do with it.

Answer 3

Personally I hold passwords in configuration files which are then distributed independently of the application, and can be changed to the specific machine/environment. In shell scripts you can source these within the main script.

However, in Perl there are a variety of approaches. You may wish to investigate Getopt::Long for command line options (and additionally Getopt::ArgvFile to store those in a simple configuration file), or look at something like Config::IniFiles for something with a little more power behind it. These are the two types I generally use, but there are other configuration file modules available.

Answer 4

There is no good solution. You can obfuscate the passwords a bit, but you can't secure them.

If you have control over your DB setup, you could try to connect by a named pipe (at least mysql supports that) without a password and let the OS handle the permissions.

You could also store the credentials in a file with restrictive permissions.

Answer 5

Since you've tagged ksh & bash I'm going to assume Linux.

Most of the problem is that if the user can read the script and locate the method you used to hide / encrypt the file then they will also be able to do the same thing manually.

A better way may be do the following:

1. Make your script so it can only be seen/read/opened by you. chmod 700 it. Hardcode passwords away.
2. Have a "launcher" script that is executable by the user and does a sudo .

This way the user can see your launcher script, examine it to see it only has the single command line. They can run it and it works, but they don't have permissions to read the source for the script that is sudo'd.

Answer 6

I'm not sure what version of Oracle you are running. On older version of Oracle (pre 9i Advanced Security) some DBA's would CREATE USER OPS$SCOTT IDENTIFIED BY EXTERNALLY and set REMOTE_OS_AUTHENT to true.

This would mean that your remote sun machine could authenticate you as SCOTT and then your Oracle DB would accept that authentication.

This is a bad idea.

As you could image any Windows XP with a local user of SCOTT could then log into your DB without a password.

Unfortunately it's the only option that i know of Oracle 9i DBs to not store username/passwords in your script or somewhere else accessible by the client machine.

What ever your solution it's worthwhile having a look through Oracle's Project Lockdown before committing.

Answer 7

For storing passwords you could do a two step encryption routine, first with a hardcoded key in your script itself, and optionally a 2nd time with a key stored in a file (which is set using file permissons to have restricted access).

In a given situation you can then either use a key file (+ key from script), or if the situation requirements aren't that great he can just use the encyrption using the key is hardcoded in the script. In both cases the password would be encrypted in the config file.

There is no perfect solution because somehow you have to be able to decrypt and obtain the cleartext password...and if you can do it someone else can too if they have the right info.

Especially in the situation where we give them a perl script (vs. an exe) they can easily see how you do the encryption (and the hardcoded key)...which is why you should allow the option to use a keyfile (that can be protected by filesystem permissions) as well.

Some practical examples for how to implement is here

Answer 8

On windows create a Folder and a File within it containing the passwords in clear text. Set the user who would run the scheduled job(script or batch) as the only person with read/write access to this folder and file. (remove even administrator). To all other scripts, add code to read the clear text password from this restricted file.

This should suffice for few.

Keywords: Password HardCoding

Answer 9

There are commercial or more advance solutions such as cyberark AIM can do it better, but doing it for free and out of box, I have been piggy back the SSH public/private key because for one, SSH key pairs most likely already created conform the security policy; secondly, SSH key pairs are already have a set of standard protocol to protect the keys by the file permission, continuous system hardening (like tripwire), or key rotation.

This is how I did it:

1. Generate the ssh key pairs if not yet. The key pairs and directory will be protected by default system protocol/permission. ssh-keygen –t rsa –b 2048

2. use the ssh public key to encrypt the string and stored in same .ssh directory $ echo "secretword" | openssl rsautl -encrypt -inkey ~/.ssh/id_rsa.pub -pubin -out ~/.ssh/secret.dat

3. use ssh private key to decrypt the key, and pass the parameters to scripts/AP in the realtime. The script/programe to include the line to decrypt in realtime: string= openssl rsautl -decrypt -inkey ~/.ssh/id_rsa -in ~/.ssh/secret.dat

PS - I have been experimenting CYBERARK AIM agentless solution. it's sort of pain requires significant changes/API changes for the API/script. will keep you posted how that goes.

Answer 10

在UNIX中，我总是将这些脚本设置为setuid，并将用户和密码信息存储在受到严密保护的文件中（整个目录树由常规用户不可读/可搜索，文件本身只能由脚本所有者读取） 。

Answer 11

Keep them in a separate file, trivially encrypted, and make a separate user in the database with read only access to necessary tables. If you think the file has been read, then you can shut off access to just that user.

If you want to get fancy, a SUID program could check the /proc//exe and cmdline (in Linux), and only then release the username.

Answer 12

I have / had a similar issue with developers deploying SQL code to MSSQL (in fact to any database on that MSSQL server, so role had to be SysAdmin) using ANT from a Solaris server. Again I did not want to store the username and password in the ANT build.xml files so my solution, which I know is not ideal, is as follows:

1. Store name / value pairs for username and password in a plain text file
2. Encrypt file (on Solaris) and use a pass phrase only known to certain admins
3. Leave only the encrypted file on the Solaris system
4. ANT build.xml runs a sudo decrypt and prompts for pass phrase, which is entered by admin
5. ANT sources decrypted file loading username and password as variables for the SQL string
6. ANT immediately deleted the plaintext file
7. ANT deploys code and exits

This all happens in a matter of seconds, and the sql username and password is never visibly accessible on the server. As the code is deployed by allowed admins in production, the developers never need to include it in their code.

I am sure it could be better, but...

JB

Answer 13

It's a shame I never saw this thread before -- it looks very interesting. I'll add my two cents for anyone coming upon the thread in the future.

I'd recommend using OS authentication on the db server itself -- REMOTE_OS_AUTHENT is still FALSE.

If you're invoking the script from another machine, setup a phrase-less SSH key and use SSH to get there. You can then pipe back the SQL results to the calling machine and it can process this information further.

Doing this avoids having to code a password anywhere. Of course, if a malicious administrator were to hijack the phrase-less key and use it, he or she could also access the user account on the DB host and could then do any operations the OS authenticated DB user could. To mitigate this you could reduce the database permissions for that OS user to the bare minimum -- let's say "read only".

Ingo