[Fwd: Re: Crypt_GPG key password practices]

[Michael Gauthier]

Hello, just though I'd forward this to PEAR-dev in case anyone else
finds it useful.

-------- Forwarded Message --------
From: Troy Perkins (TOTUS Internet Visibility Agency)
<troy.perkins@...>
To: Michael Gauthier <mike@...>
Subject: Re: Crypt_GPG key password practices
Date: Wed, 04 Nov 2009 11:31:48 -0600

Hi Mike,

Thanks for responding and your insights.  The first stage of our project is
complete as of 3am this morning.  Automation is key, in fact the second
stage will be an SSO implementation using Crypt_GPG.

Please post to pear-dev mailing list, more than happy to share!

Cheers,
Troy


On 11/3/09 11:03 PM, "Michael Gauthier" <mike@...> wrote:

> On Mon, 2009-11-02 at 22:03 -0600, Troy Perkins (TOTUS Internet
> Visibility Agency) wrote:
>> Hello Nathan and Michael,
>>
>> I am in the midst of using your wonderful package Crypt_GPG ­ Thank
>> you for creating and making available to the community.
>>
>> I have some concerns about how to handle decryption and storing and
>> using the private key password.
>>
>> Being somewhat of a novice PHP developer, I¹m following your examples
>> and was wondering if there is a better way to do this?
>>
>> <?php
>> require_once 'Crypt/GPG.php';
>>
>> $emsg = $_POST('ENC');
>>
>> $gpg = new Crypt_GPG(array('debug' => true));
>> $gpg->addDecryptKey('dummy@...', 'HEREISMYPASSWORDWORLD!');
>> echo "Message is: ". $gpg->decrypt($emsg);
>> ?>
>>
>> I don¹t feel comfortable placing my password in web directory...
>
> Hi Troy
>
> Glad to hear you're experience with Crypt_GPG so far is a good one!
>
> There are a number of ways you can make your use of Crypt_GPG more
> secure. You're correct that placing the passphrase directly in your
> source-code is a bad idea. Doing so means anyone who has access to that
> source code has access to your data. For example, if you use SVN, your
> passphrase will get saved in your commit history.
>
> The quickest way to make this slightly more secure is to place your
> passphrase in an external configuration file that is not saved in source
> code repository. This config file could be set to only be readable by
> the web user.
>
> Of course, it would be better to not store the passphrase on the server
> at all. Once you store the passphrase on a server, your data is only as
> secure as the server, which may not be as secure as GnuPG.
>
> For our use-case, we store our passphrases and private keys on external
> media. When we need the encrypted data, we connect the media to a
> computer and enter the passphrase and private key in an HTML form. The
> form is submitted over SSL. The private key is imported and the
> passphrase is used to decrypt and download the data. After the data is
> decrypted, we delete the private key from the keyring. Removing the
> private key from the server's keyring provides an additional measure of
> security as the passphrase cannot be guessed through brute-force without
> the private key.
>
> The above solution works well when you have a human in the loop. If
> things need to be automated, we use a solution as follows:
>
> web server (receives and encrypts and stores orders)
>  |
> hardened server (decrypts and exports orders over ssl)
>  |
> external order processing system
>
> In this system, the private key and passphrase are stored on a separate,
> hardened server that handles decrypting order into and securely handing
> it off to a third-party system. The server in the middle replaces the
> human in the previous solution and can be set to run on a schedule.
>
> Hope this gives you some ideas! If you're ok with it, I'd also like to
> post this to the pear-dev mailing list.
>
> Cheers,
>
>
> Mike
>

--
Troy Perkins - CEO
TOTUS Internet Visibility Agency  http://totus.us
o 210.627.1012 | tf 877.615.0343 | fx 210.375.3358
Follow me on http://twitter.com/totus
TOTUS Blog http://www.totus.us/seo-sem-talk




--
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php