Encryption idea? Will this work?

[ChenXiu]

Customer data is encrypted using OpenSSL, and then stored in mySQL varbinary column on a server.
It's now supposedly super safe -- because it can only be read using the secret key hidden right next to it.

Question: What if I encrypted that key?
And that key could only be decrypted with a passphrase submitted from my own dedicated computer?

Then I would be the only one able to read the encrypted customer data on my server, even if that server got hacked.

Obviously that would not work, because the server needs the untampered secret key in order to encrypt the data for mySQL.

Although this seems insurmountable, it feels more like a logic problem....where if you think about it long enough, the answer will come.

Any thoughts on this?

Thank you.

 

[requinix]

The server must be capable of decrypting the data on its own. Can't get around that.

But you're going about this the wrong way. First, ask yourself what are you trying to protect against?

[ChenXiu]

17 hours ago, requinix said:

First, ask yourself what are you trying to protect against?

Thank you for your reply. I am trying to prevent (as best as possible) a hacker (who has gained root access) from viewing customer details.

From all I've read, it seems incredibly stupid (like way way WAY stupid) to have encryption algorithms that "take 6 billion years to crack," but have the decryption key right there on the server, too. Dumb dumb dumb. And the programmers are "so proud" to have created those 6-billion-year algorithms -- don't they know that if you put the key right there, too, then anyone can read the stuff?

According to what I've learned, it appears I only have TWO (2) choices:

1.) If I want customers to be able to "reprint packing slip," I need to have the decryption key right there on the server, too. (Don't steal my car, but the car keys are taped to the windshield)

2.) If I don't want any hacker that has gained root access to read the encrypted files, then my customers won't be able to "reprint packing slip."

Hmmmm. wait a minute (wheels always turning in background)....  what if each customer had their own password, hashed on my end so they can access their own data? No. That wouldn't work, because the data is still has to be encrypted and you need that decryption key. And if each customer had data that only they could read using a randomly generated key, then I wouldn't be able to read the data.... hmmm.

I'm still thinking this is a logic puzzle. Nobody's figured it out yet. I'm going to be the one to figure it out! (with a little Moderator help 😀 )

Edited July 13, 2021 by ChenXiu

[requinix]

1 hour ago, ChenXiu said:

I am trying to prevent (as best as possible) a hacker (who has gained root access) from viewing customer details.

If they have root access then there is nothing you can do. No amount of encryption can save you from that.

[ChenXiu]

Nice work.

[requinix]

So once again, what are you trying to protect yourself against? People getting root access on your server is extremely rare and not something regular people need to worry over, but SQL injection allowing someone to scrape your database is something to be concerned about, and it's not unreasonable to take measures to protect specifically what's in your database...

[ChenXiu]

11 hours ago, requinix said:

your server is extremely rare

Respectfully, I do understand how rare it can be. And, again, I'm trying to protect myself against what happened when the PHP Freaks Forum got hacked by trying to figure out a way to:
a.) Allow customers to be able to retrieve their own data (e.g. "retrieve an invoice or packing slip")
b.) Limit access to all data to just one user at one specific computer.

To me, protecting against SQL injection seems trivial (in my case, $data = preg_replace( '/[^\d]/ ' , ' ' ,  $data ); is all I need).

However, ever since the day a friend said, "Hey come and look at this," and I saw a file name "PWND" in their root directory, I've been concerned about the issue.

I realize this may be beyond the scope of this forum (maybe my question better suits an encryption-related forum), but in my opinion some of the members right here in this forum have the sophistication, the 'outside-the-box' thinking, and the know-how to potentially propose some heretofor undiscovered methodologies.

Thank you.

[kicken]

Security is all about balance.  You have to have to strike a balance between making the system usable and making the system secure, which means making a determination about how likely it is a particular scenario is.  As mentioned, an attacker gaining root access is generally rare.  Trying to protect against someone with that level of access severely hurts your overall system usability, so in general that's considered a "game over, hackers won" scenario.  Your efforts are better spent trying to prevent that scenario in the first place rather than maintain security in it.

The only real thing I can think of that might be helpful in such a scenario is to require a passphrase on boot/startup which must be entered manually by you.  That narrows the scenario to the hacker needing to gain root privileges without restarting.  The downside to this is that nothing will work after a restart until you are able to login and provide said passphrase, which means you (or someone) has to babysit it pretty much 24/7 or accept downtime.  Think about if there's a brief power outage just after you went to bed, your system will be offline until you wake up 8 hours later, notice the problem and fix it.  Is all that hassle worth while for protecting a packing slip?  I'd say no.

Your idea of just storing the data encrypted in the columns has downsides long before this level of problem anyway.  You can't effectively query against such encrypted data which can make potential data processing way harder than it needs to be.  What if some day you want to see which state/country you do the most shipping to.  If all your customers shipping addresses are stored encrypted then you can't just do a simple query grouping by state/country, instead you have to query every row, decrypt every row, and tally it all up.  Fine/doable for a one-off reports, less acceptable if you want to get such data more frequently (monthly/daily say).

tl;dr, encrypting everyone's data is nice in theory, but not always practical.

[requinix]

3 hours ago, ChenXiu said:

I'm trying to protect myself against what happened when the PHP Freaks Forum got hacked

It's been a few years but IIRC (not that I have any reason to doubt it) what gizmola said is what happened: someone used an exploit in IPB to upload a PHP file they could then browse to. Besides updating IPB, we also took measures to prevent PHP from running files in the uploads directory, so anyone browsing to one will only get a dump of the source code.