Forum OpenACS Q&A: Using openssl to encrypt/decrypt strings

1: Using openssl to encrypt/decrypt strings

Posted by Jerry Asher on 09/07/03 03:07 PM

A client wants to store, well you know, credit card data in the database.

Here's what I am thinking of doing, and I'd like your help in making what I do actually useful.

I created two functions: cc_encrypt and cc_decrypt that use openssl to encrypt and decrypt a string. I then plan on storing the encrypted binary string in the database (along with data detailing the encryption parameters apart from the password.)

openssl bf -pass pass:${password}

will use the blowfish cipher to encrypt stdin, sending it to stdout using the password.

openssl bf -pass pass:${password} -in infile -out outfile

will use the blowfish cipher to encrypt infile, sending it to stdout using the password.

and

openssl ... -d

will decrypt

Question one:

What's a good cipher to use? blowfish, des3, ...?

Question two:

So this encrypts the database but now I have this $password floating around. The password can be set with an environment variable, a string as I show here, or a file somewhere in the filesystem. Is there a reasonable secure and easy to implement way to manage this password?

Question three:

I have gotten this working using the temp file approach, but I would like to get rid of the temporary files both for file hygiene and privacy concerns.

The problem is that openssl creates binary strings, and I can't figure out how to make a binary process pipeline (to use the Welch terminology (p110 of PPiTaT) out of exec, or out of |open.

Can anyone help? What magical incantation can I use to get rid of the temp files?

Question four: assuming the password can be managed, and that I can get rid of the temp files, what are the security implications of this?

Thanks,

Jerry

2: Re: Using openssl to encrypt/decrypt strings (response to 1)

Posted by Chris Davies on 09/07/03 06:29 PM

CISP from Visa has very specific recommendations regarding the storing of credit card data.

Search for November 2002 Operating Guidelines and it should find a PDF that details the requirements you should follow.

Also, if I recall, violation of the statues that they have set forth carries a $50000 USD fine for the first occurrence, a $100000 USD fine for the second occurrence and management can then set the fine level. Terms are based on a 12 month rolling period.

Mastercard and American express have similar recommendations but Visa is by far the most strict.

Basically, if you store the card number, it must be stored on a machine that cannot be directly hit from the internet, and storing the CVV2 number is also not allowed. If I recall, the recommendation is for Triple DES if you must store the card data.

You might check your gateway provider, although I don't believe verisign has any one-click capabilities.

As for the password, what older processes used to do was require manual entry when the server process was restarted -- that way it was only in memory. Storing it anywhere on a filesystem is probably not a good idea.

If you are running linux, you might take a look at some of the SELinux patches with the secure filesystems.

3: Re: Using openssl to encrypt/decrypt strings (response to 2)

Posted by Jerry Asher on 09/07/03 08:24 PM

Interesting. Thanks I'll look for that. I would prefer not to store them....

4: Re: Using openssl to encrypt/decrypt strings (response to 2)

Posted by Jerry Asher on 09/07/03 08:49 PM

Here's the basic information: http://usa.visa.com/business/merchants/cisp_index.html With an interim pdf questionnaire/checklist at http://usa.visa.com/media/business/cisp/ComplianceQuestionnaire.pdf

However, it's actually pretty weak. The fines are stiff, but since I assume they don't want to shut down so many customers, the requirements as suggested or implied in these two docs (the final statement of requirements hasn't been posted) put up a show, but not much more.

The two suggest (but don't seem to require?) that there should be a NAT firewall between the machine and the net, that your machine be kept up to date, and that passwords are stored encrypted, cc info stored encryped that you have various security policies in place and basically that you use SSL for any communication transmitting cc information. It's not clear if telnet or rlogin are allowed (but which ACS user is still accepting them for incoming connections?)

IANAL, but it appears an openssl des3 encryption, ns_openssl, some form of firewall including a SOHO NAT router and a bunch of policies will do the trick.

Who needs the CVV2 (the 3 digits on the back of the card) information? Verisign's payment gateway sure doesn't, so there's no need to store it in the db.

Thanks for pointing this out. I will use des3 and not bf, and I will point the document and the fines along to the client.