Of course, making sure CGI isn't readable is the only real bastion you've
got with interpreted Perl.  Some other things to think about:

1) Make sure the SQL server is locked down!  Ensure that it'll at a
minimum accept connections from only certain IP addresses.  Don't rely on
mere password encryption, but use every tool you're given to minimize the
available access.

2) One way you might occlude the passwords a bit is to read them from a
configuration file that's not in the cgi-bin directory, but is accessible
to scripts running out of it.

3) Encrypt the passwords in the configuration file, and have the script
decrypt them.  That ensures that you'd need both the CGI script and the
config file in order to get the passwords.  (The password decryption key
would still be plaintext in the script.)

4) Skip the config file, and write a small C program that will emit the
encrypted passwords only when executed, and only if certain qualifications
were met, i.e. it was called by the proper script and by the proper user.
Have the perl script run the program, collect the encrypted password, and
decrypt.

Ideally, the user that calls the script would have an authentication token
that they would pass on through the script to the SQL server, removing any
reliance on trust between the script and the SQL server.  Kerberos
supports schemes like this, but I'll bet you that your components do not.

Doug



On Thu, 29 Aug 2002, brian gilbert wrote:

> I asked earlier about a way to hide my password in the script, when calling
> an SQL connection with a line like:
>
> my($db) = new Win32::ODBC("fileDSN=myodbc.dsn; uid=myID; pwd=mysecret");
>
> No answers, so let me ask another way:  what steps should we take to keep
> our scripts and embedded passwords safe from prying eyes?
>
> I've found very little on how to secure my cgi scripts on the server.  Once
> I moved them to a new server and was horrified to find that when they were
> called by http, they gave a listing instead of running!
>
> So, what SHOULD we be doing?  Any pointers or links?
>
>
> -Brian
>
>
> --
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to