One solution is to set a perl variable in a conf file that is only 
readable by root. The parent httpd process can read this, and the 
children can inherit it, but its not visible in the code.

If your httpd children need to be able to read in the password, then 
you'll need less restrictive permissions on the password file.

Of course you need to be able to trust your application developers not 
to dump the variable out into the world.

A slightly better method is to abstract away from the connection method, 
so that your application developers don't use the password directly, but 
call a library routine that hands them a connection object, using the 
password variable under the hood.

I've seen this used, and it worked quite well, although having the 
password in plain text anywhere is a little disturbing.

A slightly better approach would be to keep a file of blowfish encrypted 
keys to be read during startup, and to somehow pass the key to decrypt 
the keys in manually during Apache startup, via a prompt. Stronghold 
does this at startup, in order to get the passphrase for your 
certificate. I'm not sure exactly how to do this from scratch, but I 
believe there are modules that allow you to embed perl in conf files, 
which might work, or you might be able to do it via startup.pl



On Friday, June 15, 2001, at 12:44  am, Kevin Schroeder wrote:

> This would make an interesting discussion because I've had the same 
> question
> come up in my mind.  How do you encrypt things on your server without 
> giving
> out the passphrase?  Is it even possible to keep the key in the same
> location as the program using it and still maintain security?
>
> Kevin
>
> ----- Original Message -----
> From: "Benjamin Trott" <[EMAIL PROTECTED]>
> To: "modperl" <[EMAIL PROTECTED]>
> Sent: Thursday, June 14, 2001 5:00 PM
> Subject: Re: ssl encryption
>
>
>>> When apache is serving a ssl connection, I assume that everything
>>> sent back and forth between the server and the client is encrypted.
>>> I want an mod_perl script to encrypt/decrypt credit card numbers
>>> obtained over the ssl connection for storage in a db on the server.
>>> Is there any access to the same routines that apache is using for the
>>> encryption or do I have to use some other module.  If I have to use
>>> another module, what would be a good choice?
>>
>> You could use either an asymmetric cipher or a symmetric cipher.
>>
>> An example of the former is Crypt::RSA (Crypt::DSA is another, but DSA 
>> is
>> used only for signing/verification, not for encryption/decryption).
>>
>> A good, fast example of the latter is Crypt::Blowfish. Used together 
>> with
>> Crypt::CBC, you get Blowfish in CBC mode:
>>
>>     use Crypt::CBC;
>>     my $cipher = Crypt::CBC->new('passphrase', 'Blowfish');
>>     my $ciphertext = $cipher->encrypt('data');
>>     my $plaintext = $cipher->decrypt($ciphertext);
>>
>> In other words, you use the same passphrase to both encrypt and decrypt
> the
>> data (ie. symmetric).
>>
>> Personally, I think I'd use a symmetric cipher, but the thing you have 
>> to
> be
>> careful of is leaving your passphrase around in plain text (eg. in a
>> script). Doing this negates many of the benefits of encrypting the 
>> data in
>> the first place. :) Sadly I'm not sure of the best answer to this 
>> dilemma.
>>
>> bye,
>> Ben
>>
>>
>
>

Reply via email to