Forum Moderators: open
Does anyone know of a free ASP component which I could use to do this?
I've asked my host if they'd install ASPencrypt, but they have suggested I find a free component for them to install.
I want to encrypt credit card data before storing it in a database or possibly emailing the information.
You can probably store the CC encrypted in the database using on of the SQL commands to encrypt it as your write it. "password" or "md5" are two I use with mySQL.
As for emailing, it's not secure at all. I wouldn't email my credit card information. The only way to get the CC# that is secure is through an HTTPS page.
Does anyone know of a free ASP component which I could use to do this?
You should consider that if people get access to database then they are likely to get access to scripts that do encryption and just take the key out and decrypt these.
Script hosting boxes are most vulnerable and if access is gained to them then attackers can use script to connect to database and run queries decrypting everything they need even if cc's are encrypted inside database engine by database itself.
IMO the most secure way is to do what we (I even) designed in my previous place - we move cc's offsite and all charging took place there. It was additionally encrypted, but the key thing was not to keep cc's on the same site with website. This might not be practical for small firms though, but its prudent to take security seriously.
So to sum up - don't be under illusion of security if all you do is encrypt some data without guarantee that scripts in question won't fall into wrong hands (with decryption keys).
You should consider that if people get access to database then they are likely to get access to scripts that do encryption and just take the key out and decrypt these.
Do I have to keep the decryption key on the server? Is it possible to use a system like PGP where a public key is used to encrypt and a private key is used to decrypt. This way I could keep the private key off the web completely. We would download the card details to a local computer, then decrypt the card info there.
IMO the most secure way is to do what we (I even) designed in my previous place - we move cc's offsite and all charging took place there. It was additionally encrypted, but the key thing was not to keep cc's on the same site with website. This might not be practical for small firms though, but its prudent to take security seriously.
Not 100% sure what you mean here.
When you say offsite, do you mean have the database on a different web server? I don't see how this is any more secure, because if someone hacked your script, they would be able to see where the database was stores anyway.
With reference to your mention of charging offsite, we want to be able to download the encrypted data to a local computer. We'd then decrypt the data and import it into our office billing system (nowhere near the web). Is this what you mean?
Do I have to keep the decryption key on the server?
If you use symmetrical encryption then yes - key to encrypt is the same as the one to decrypt and if you intend to do anything with data on server then you will need to keep that key there.
Good question about assymetric encryptions (PGP) - this will require public/private keys. Data encrypted with public key can be decrypted only with corresponding private key. So, if you keep private key on server then you will be as exposed as if you used symmetrical encryption. And you will need key to decrypt credit card if you indend to do anything with it (like charge).
If you want just to encrypt data to transfer to your other office (like described below) then you might as well just connect via SSL and do transfers over it then delete data. Or try to delete it - the data you delete is not really deleted it is just marked as deleted and in principle can be recovered.... pain is not it?
When you say offsite, do you mean have the database on a different web server? I don't see how this is any more secure
By saying "off-site" I mean not connected to your webfarm - there should be connection from the database side to webfarm get new credit cards to store, but actual web or anything else should not be able to connect to the database - completely firewalled.
We'd then decrypt the data and import it into our office billing system (nowhere near the web). Is this what you mean?
Yep! Just make sure its not easy to get into your organisation - particularly make sure you get good anti-virus to intercept all those nasty attachments, this is the best way to get inside someone's firewalled network - all it needs some naive people who will run attachment!
I hope it makes sense.
Thanks for you input on this. From what you've said, this is what I'd like to do...
1) Take credit card info from a form
2) Ecrypt the card number (using some form of asymetric encryption), then write it to a database
3) Download the information later, then decrypt the card details locally using the 'pricate' key
This way the card details are pretty safe don't you think?
Next question (back to the start again) - anyone know of a free (preferably) ASP component which can do the encryption bit?
You should be okay, but never forget that it is possible for people to hack server and modify scripts to write plain text credit card into file - pro-active server monitoring to check if any scripts changed without authorasation is a prudent thing to do.
This is pretty much how the scheme that I designed operated, sadly not component for sale - was all in-house Perl code!
I've found this free component called RSADLL which uses public and private keys.
[sloppycode.net...]
Not knowing much about encryption, do you think it's OK? It only uses 40bit encryption, but I'm struggling to find free asymmetric components.
Not knowing much about encryption, do you think it's OK? It only uses 40bit encryption
GPG currently defaults to 1024bit keys for RSA. Asymmetric key sizes (eg RSA) are usually much larger than symmetric key sizes (eg AES, Triple-DES) for the same security. For symmetric keys, 128bit is commonly accepted as secure, for asymmetric, 1024 to 2048bit. 40bit symmetric keys would take a couple of hours to brute force crack. 40bit asymmetric keys would fall much quicker.
This supports RSA encryption up to 2048 bit.
What do you recon?
Anyone used this component before?
Also it is easy to confuse what actually happens with assymetrical approaches - because 512/1024/2048 bit keys take heavy toll on systems few people actually encrypt FULL data using RSA - in SSL and others only random symmetrical key is encrypted with assymetrical encryption, and the actual data is encrypted using symmetrical cipher. This is exactly what public/private key approach was designed for - secure exchange of keys used to encrypt main data.
In any case there is no perfect protection - if people can break into your server then they will just change code in your script to log plain text credit card number before you encrypt it.
Depends on how secure you can go of course, and if I was Top 10 site on the Net then I'd go totally paranoid, but for most sites simple good (128bit+) symmetrical encryption with subsequent transfer of data offsite is sufficient.
I know assymetric is slower than symetric, but do you think it'd make much difference when all we're encrypting is a 16 digit credit card no?
Anyway I really think that you just being overly paranoid. As I said just encrypt using strong (128bit+) symmetric crypto and move data offsite - if you do that regularly (every X minutes) then it does not matter what and how you encrypt it so long as it never gets written on disk in plain text.
