3

In this very simplistic but realistic scenario, I have 2 combo web/database servers (A) behind a load balancer and a single IP address. They also permit access only from one IP address -- the client (B). On each database server, we need to store read-only secret identity information (like email address, username, etc.).

I need a solution that prevents a hacker who may have compromised server (A) from being able to do anything with the data unless they also gain access to server (B).

I need a strategy where client server (B) uses a public key from a private/public API key pair to find a match for this identity information (like an email address) on server (A), and then, without server (A) evaluating that result, return the result back to (B) for evaluation using its private key. The theory being that if the hacker gets root level access to server (A), they can't do anything with it to decode the data, not even with brute-force attacks on md5(), sha1(), sha256(), or against any hashing algorithm.

Here's a strategy that won't work, as an example. Imagine you have PHP's libsodium (a common public/private key system). You use it to encrypt the data and store it on (A). Then, when (B) wants to do a lookup, they send in the public key, it gets mated with the private key on (A), a hash is generated, and that hash is checked against a hash in the database. (So, you find if hashed email request matches a hashed email address in the database.) The problem with this strategy is that if server (A) is compromised for root-level access, all the attacker has to do is intercept the web traffic to find the public key from (B), combine it with the private key from (A) in the PHP server scripts, and then use that information to run a powerful brute-force script to break the hash so that the entire database can be decrypted. This brute-force attack has been used to break md5() and sha1(), but can be used to break even someone's sha256 or other hash API.

Right, so that won't work. It would be better if there was some way that the result of the match can't be interpreted on server (A) and must be sent back to server (B) for final evaluation, which then requires server (B)'s private key to decrypt the result.

Using PHP, can you explain a programmer API key strategy where a compromised data store will yield no useful information to a hacker unless he has the private key of that programmer's public/private key pair?

  • Does (A) need to be able to access this secret identity information, or is it just holding it for (B)? – Dan Pichelman Jan 12 '16 at 20:49
  • It's holding it for (B). The idea is that if a hacker hacks (A), without a private key from (B), he's going to be out of luck. And no amount of intercepting the web traffic on (A) is going to help. I'm just trying to do this in the most secure, industry-standard way. – Volomike Jan 13 '16 at 1:51
  • In that case, why does (A) need any knowledge of encryption at all? Just have (B) pass in the data already encrypted. – Dan Pichelman Jan 13 '16 at 13:46
  • Okay, I posted a preliminary answer. Do you think this can work and is a best practice? – Volomike Jan 13 '16 at 20:56
5

As I mentioned in a comment, I'd do all the encrypting/decrypting on (B) and let (A) do nothing but store the data.

As an example:

This happens on (B)

string encryptedKey = encrypt('John Smith');
string encryptedData = encrypt('121 Main Street');

(B) sends the 2 encrypted strings to (A).

(A) stores the 2 encrypted strings in a key/value database.

Later, (B) can request the data by sending a message to (A) send me the value associated with the key "xxx" where xxx is the output of the encrypt('John Smith') call.

(A) has no knowledge of encryption at all. (A) also does not know what is being stored - just an "opaque string" for the key, and another "opaque string" for the value.

(B) can use symmetric encryption if desired - it doesn't matter.

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.