NYCPHP Meetup

[Rolan Yang]

Dell Sala wrote:
> Rolan Yang wrote:
>
>> Whenever I need to store credit card data, I encrypt it with GPG 
>> before storing it in the database. The private key file is not to be 
>> stored on the same machine and should definitely not be accessible by 
>> the web server!
>
> That's always been my understanding. But it occurred to me that the 
> private key is useless without the pass-phrase. What if the secret key 
> is stored on the same machine as the encrypted data, but the 
> pass-phrase isn't?
>
> As long as the pass-phrase is submitted along with every request that 
> shows decrypted data, the pass-phrase never needs to be stored on the 
> server ... unless of course the pass-phrase is somehow accessible by 
> the use of shell_exec.
>

The strength in public key encryption lies in the fact that the private 
key is not accessible by the "evil" third party. The passphrase is a 
secondary level of defense which protects in the event that the private 
key file is stolen. I don't have numbers off the top of my head, but 
it's far easier to brute force crack the passphrase than to crack a 
message encrypted with the private key.

> Dan Cech wrote:
>
>> A much better approach is to use the proc_open function to execute the
>> process and allow you to provide the passphrase directly to the gpg
>> process on stdin and read the decrypted data from stdout.  This way the
>> passphrase & cleartext are much less vulnerable to simple sniffing by
>> other users of the machine.
>
> This sounds like a good suggestion. It seems to solve the shell_exec 
> problem.
>
> I'd just love to create a simple solution for storing sensitive data 
> without requiring a special decryption setup on the client side. What 
> do you think? Am I playing with fire?
>
To avoid storing or transmitting the private key, you might want to 
consider using... gasp!.. javascript to decrypt the payload on the 
client side. There are probably some javascript gpg examples floating 
around on the net. I remember a company called hushmail which used 
something similar to implement encrypted webmail. Trusting the browser 
for security is a slippery slope though. If you don't control the 
content, a cross site scripting hack could easily steal the private key 
from your cookies or right out of memory. But that is another can of worms..

~Rolan


I believe hushmail used to (and may still do) use an scheme where an 
encrypted message is sent