views:

126

answers:

5

I have to handle some sensitive data in my application, such as passwords, credit card information, etc. What are possible security risks I could have and how can I avoid them?

A: 

I would be inclined to perform some form of reversible encryption on the information as it's being stored, something like:

$card = myEncryptionFunction($input);

A little more information on the nature of your application wouldn't hurt though.

EvilChookie
+2  A: 
  • Don't store Credit Card Information (in some jurisdictions, you might be breaking the law by doing so, or at least falling foul of a commercial agreement)

  • You don't say where your sensitive data is stored, but encypting it is the usual approach. There are two forms symmetric and asymmetric. Symmetric means you use the same key for encrypting and decrypting. Asymmetric consists of a public/private key pair.

  • Passwords: store only a salted hash (i.e. un-reversible) of your passwords, and compare with a similarly salted hash of an entered password.

Mitch Wheat
A: 

I'd be using reversible encryption on the database data. Make sure this data doesn't seep into log-files too, log derived information instead. Consider how yoǘ'll handle different environments - normally you want to not use production data in your test environments. So even though you may consider copying production data back to test systems, you should probably generate fake data for the sensitive parts.

krosenvold
+1  A: 

Be aware that you really shouldn't store credit card info in any shape or form on a web server.

Bit of info on doing this in a web environment, which is my background:

If a website (or any application) needs to store card info, it should comply with the PCI DSS (Payment Cards Industry Data Security Standard). Amongst other things, it requires that the data be held encrypted on a separate server that isn't publicly accessible (IE: isn't hosting the site) and has a separate firewall between it and the webserver. Penalties for not complying are potentially very large in the event of any fraudulent activity following a security breach, and can include them ceasing working with you - it pretty much reserves the right for the them to chargeback any losses from the fraud to you (from my interpretation as a non legal person)

More on it here: https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml

Obviously, this may be expensive compared to shared hosting, as you immediately need two servers and a load of networking gear. Which is why people don't often do this.

benlumley
Good information! The application might be not Web based, but information is useful anyway.An alternative is to redirect to a 3rd party secure payment platform (bank...), of course.
PhiLho
A: 

It's been already said that you shouldn't store CC especially CVV2 information in your database, avoid where possible.

If you store CC + CVV2 then consider using asymmetric encryption and store your private key in another server. Otherwise an attacker who can access the data 99% can access the key and the whole encryption would be pointless.

Passwords should be stored as one way hashed.

After all these you need to ensure that your application is secure against vulnerabilities such as SQL Injeciton, remote code execution etc.

Don't forget Even when an attacker can't read previous data they can plant a backdoor for the next data.

dr. evil