CODEWITHSUNDEEP
phpmysqlsecurity
Brian Huether
Brian Huether

Reputation: 179

Pragmatic approach for securing sensitive data in PHP/MySQL app?

I have a form on my site that collects some fairly sensitive data (personally identifying data). I have been reading on here how best to secure and am somewhat overwhelmed by the varying opinions. First, let me explain what I have done so far:

So far, the data is stored in the DB as plain text, and this is what I want to change. I read about MySQL's built in AES function and BLOBs, but I read on here that a lot of people recommend against it (though others think it is fine...). I know the ultimate approach is probably using keys externally stored elsewhere, but I am also trying to keep things as simple as possible, while being sufficiently secure. If I am taking other measures to safeguard (as mentioned above) will the MySQL functions give me a decent level of security?

Also, when a user submits the form, they receive an email with their data. I confirmed that the email seems somewhat secure in that the header shows

Received: from myhost (myhost. [IP])
    by mx.google.com with ESMTPS id
    br2si8908071ojb.205.2015.04.22.08.36.02
    for <someemail>
    (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);

Anyway, before I start implementing some sort of secure storage in the db, I was curious what you all recommend as a nice pragmatic approach.

Upvotes: 1

Views: 116

Answers (2)

TheMonarch
TheMonarch

Reputation: 617

A couple of things.

First, don't use magic quotes; especially if you're already escaping values with a built-in class. This will lead to potentially double-escaped input, which is bad. Furthermore, magic quotes are generally not considered secure (because they're magic). Source: http://php.net/manual/en/security.magicquotes.php. From the manual:

"Warning This feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0."

Second, you'll want to ecnrypt data that you want to see again. Examples of this would be names, dates, credit card numbers.

What you don't want to see again, hash. By that I mean if you only need to compare data and not read it like in the case of a password, use SHA256 (or better) to mathemtically remove the possibility for the data to be reversed.

As for salting (which another answer mentioned) this refers to the practice of adding a random string into the encryption or hashing to avoid an attack known as a rainbow table. This process looks like this (pseudocode)

var salt = "9285gh8927thg0nfc30897gnvh2087vgh 8g7v2n";
var data = "sensitive data";

var encrypted_data = encrypt(data + salt);

As for data filtering, you'll want to do more than just deal with SQL injection (though that's a good start). You'll also want to take a look at XSS (OWASP: https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29)

Also, as an aside; you should have database users that only have permission to do one sort of action (ie: a user for writing to the database, and a user for reading from the database).

Hope this helps!

Upvotes: 1

blazej
blazej

Reputation: 163

I think a lot depends on your use case. What do you need to do with this data later? I would definitely encrypt and salt data before inserting it to the database, I would try to make sure that no other part of your app can be easily hacked with SQL injection (lookup Joomla hacks, is it possible?) and the such, and I would review how the admin login is made to make sure it couldn't be a vector for attacks.

A bigger problem that I see is that sending this "sensitive" data via unencrypted e-mail might just about eliminate all other attempts at securing it. I think the header you're showing is only about your connection to the SMTP server, but there this content will linger on Google's servers forever, it will be sent to a possibly less secure destination server, and it may be retrieved using an unencrypted connection.

Upvotes: 1

Related Questions