Encryption of data

encryption data security

[frozenpeas]

In e-commerce, I see much talk of people encrypting credit cards but not a lot of discussion on encrypting customer details including name, address, zip codes etc

With the amount of sites being hacked and identify theft I would have thought that this was as important. After all, credit cards are easily cancelled and replaced but identity cannot.

Many people use a payment gateway service to handle the “safe” keeping of customer credit card details but then forget to bother about securely storing customer details on their own website.

Therefore, my question is what methods do you use/suggest to others for handling security of customer details?

Forgive me for posting this here, as I could not find a dedicated security thread on this forum.

[lorax]

You're in the right forum. When it comes to admin areas or forms that accept customer details, you can always wrap the connection in SSL. Simply invoke the SSL (https) and the transfer of the data should be safe. Then the trick is to keep the database secured or not to store the data at all - eg. send it along in an email after a handler processes the form details.

[frozenpeas]

Thanks
My question was really aimed at the storage of data as opposed to the secure transfer of inputted data through forms.
Unfortunately, in an e-commerce scenario customer details have to be retained in the database for order fulfilment.

I would be interested to hear what others feel are the minimum security methods required for storage of customer data e.g. names, addresses, zip/postcodes (not cc cards)

[digitsix]

I don't do any encrypting of customer data, the overhead is not worth it. The only thing a hacker will get is someone's name, email, address and phone number, and what they bought... Its not enough to steal someone's identity, the only thing that data would be good for would be spamming.

Credit cards are not stored on the system, just the last four digits and expiration.

[digitsix]

To add to my previous post, part of the overhead i mentioned is the fact that the client would have to enter a pair secret every single time they viewed an order. The reason for this, is the only way to actually securely encrypt data in a database like you mentioned, is by using private / public key pairs. The server uses the public key to encrypt the data, and only the private key can decrypt the data... in order for this scenario to be secure, the private key cannot be accessible by or be on the server at all. So in this scenario, the only way your "order manager" screen would be able to load up any of the order data, would be for the employee to type the secret password every single time, and the system would have to coded to work like this.

[frozenpeas]

Thanks
In your case it seems that you maybe only deliver digital goods hence the name, email and phone number.
What about delivery of actual goods (dvd's, ipods etc) where the customers delivery name and address is required to fulfil that order?
Or do you only capture and store customer details within your payment gateway?

Most store systems that I know of capture and store customer name, address, postal/zip codes after the order has been processed by the payment gateway but do not apply any form of encryption.

I know that the public/private key is the only "true" way to fully secure details but there must be other options for making it as difficult as possible for a hacker to easily gain these details.

Anyone have any ideas how?

[digitsix]

If you are using a payment gateway, then you shouldnt need to store credit card numbers except for maybe the last four digits along with the transaction id's for doing refunds or capturing funds and what not, so you really do not need to encrypt any of that data.

Now if you were going to save full card numbers and info, as to run the card on a physical P.O.S. machine located at the business, encryption like I described is pretty much required and how I set up my clients that demand to use their physical POS.

Encrypting the other data, like addresses, email, name, phone etc is not worth it because doing that will make simple functions like order searching, updating, viewing, etc impossible in some cases and about 1000% more dificult than they need to be to code.

If you are worried about hackers, just make sure you keep up to date with securityfocus.org's vuln and bugtraq RSS feeds (check on f-secure.org too) and watch for vulnerabilities on services your server runs. Do not give clients SHELL access on production servers so that local exploits cannot be used, and obviously make sure all of your code is is secure and not "sql-injectible".

You could also pay for the "hacker safe" service thats out there, that will daily probe your server with a list of recent exploits to see if you are vulnerable to anything, along with testing your web code for xxs and injection vulnerabilities.

If you're still convinced you want to encrypt your data simply, you can just google "encrypt decrypt strings using <insert programming language here>" to find plenty of docs on how to do it in your launguage.

If you're using PHP, i highly recommend the PGP class you can get here:

hxxp://pear.php.net/package/Crypt_GPG/redirected

[digitsix]

GPG class i mean :P

[frozenpeas]

Thank you,
as you will have read in my original post this is not about CC encryption but about securely storing customer details like Name, Address etc

Encrypting the other data, like addresses, email, name, phone etc is not worth it

With all due respect (and don't take this the wrong way), this leads me to believe that you don't care about identity theft (perhaps unless it happens to you) so perhaps you are the wrong person to answer my original question.

[digitsix]

I'm not sure someones name, address and email address are enough to steal their identity, maybe if you were reallllly good. I'm pretty sure a social is required for that, or at the very least a dl#. I guess i'm not an expert on it though, since I've never stolen anyones Identity.