1

I'm currently building a B2B e-commerce site for a client using WordPress. We sell industrial machinery ranging in the upper $100k-$400k price range. My client would like to have their financing form online where customers/businesses enter bank account information, as well as social security numbers. He wants this form to be emailed to our financing group to process. Instead of emailing this form, could I keep the data on my SSL server and encrypt it some way then provide a login link for our financing group to use, enter a key, then display the sensitive information? We are trying to eliminate the need to fax or mail an application.

We have 2 servers, an in-house MS SQL 2008 server and a MySQL/Nginx server WordPress is installed on.

After reading through many posts, what my client wants to do is a huge risk for users and our company. I'm not a security specialist, just looking for some feedback on what I should/could do.

6
  • 2
    PCI DSS, man. And I'm sure other standards. That's some serious PII you'd be handling. Then again, sending it via e-mail (depending on the MX servers / MTAs used) may well be far worse. If at all possible, you want to not have to handle sensitive information; if a middleman qualified to handle their details does it instead of you, and they have all the necessary compliance, you should be off the hook. – Parthian Shot Jul 22 '15 at 0:47
  • 1
    Don't email bank PII like bank account and social sec numbers. Email can be read by intermediate mail servers. It is absolutely not secure. – Neil Smithline Jul 22 '15 at 0:56
  • 2
    @ParthianShot PCI stands for Payment Card Industry. Bank account numbers and social security numbers are not credit card data so exactly zero of the PCI DSS requirements would apply here. HOWEVER as stated this is some SERIOUS PII and just because the PCI DSS isn't directly applicable doesn't mean it should be ignored. The PCI DSS does contain A LOT of security best practices. – JekwA Jul 22 '15 at 1:04
  • Acceptable risk. A good point to note would be: when it comes to payment data, always try to offload it to a third party and not store any cc details on the local server. – munchkin Jul 22 '15 at 7:40
  • 2
    The title of this question is pretty misleading. It sounds like the site has plenty of sensitive data going to and from it. – hololeap Jul 22 '15 at 12:52
4

It sounds like you have plenty of sensitive information on your website!

Even if your site contains no sensitive information, though, implementing HTTPS is a sound decision. Insecure HTTP connections are vulnerable to a man-in-the-middle (MITM) attack, allowing an attacker to impersonate your site with ease. Clients have no way to be sure they're actually connected to your server, rather than someone else's pretending to be yours.

HTTPS provides authentication by allowing clients to verify your server's identity, as well as confidentiality by preventing third parties from snooping on your traffic.

3

First of, HTTPS only protect data while in transit, it does not protect your data afterward. Therefore, you will need to implement security for this data at rest.

Designing a fully secure system is a really, really difficult task and evaluating what is an acceptable risk and what isn't is far from trivial. I would really suggest you seek advise from a professional security consultant (audit firms have access to such profile).

That being said, here are a few pointers on how you might want to go after this task:

  1. First, you will need to estimate the value of the data you want to protect. This is VERY important because it will let you decide what security measure are necessary and which one are overkill (security always has a cost). Don't forget that this value should include the cost should that data be lost and should that data being stolen/disclosed.
  2. Make sure you actually NEED all the data you're collecting. The simplest way to protect sensitive data is not to request or store them so you can minimize the risks (and costs) by reducing the amount of data you're storing.
  3. Check if you'll need the sensitive data on the front server ever again. If not, a pretty simple - yet effective - implementation is to create a secure, one-way path for the data: implement a back-end server that will accept the data with a simple API (through a secure connection) but will not have anything else exposed. Another way of protecting this data is to encrypt it (for instance, using PGP) with a public key and keep the private key off the server. That way, the sensitive data cannot be easily retrieved as long as the private key isn't compromised.
  4. In all cases, you will be better served by having a separate server for storing your sensitive data and performing access control. This server shouldn't be accessible from the outside, only from your front-end system. If an attacker gets hold of your frontal server, they will still need to gain access to this system to reach your sensitive data. The API used for contacting this secure server should be carefully designed, though.
  5. Data at rest should be encrypted as well. Ideally, you will use a HSM to store the keys and not use transparent encryption (neither in the storage, nor in the database).
  6. When you're done with your design have it audited.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.