help for choosing an encryption method for a database column

Question

I'm storing some phone numbers in the database which should kept totally secret (they're supposed to access via web). BTW, because of the position of these people, I need to prevent any chance for leak of their numbers. So, the only solution I could thinking of is Encryption.

As the database could contains bunch of data, I won't encrypt the database entirely. Also, I actually prefer to use different key for each person to encrypt their phone numbers, so in the case of leaking one key, the other phone numbers should be safe at least. The problem is that other people also need to send SMS messages via the application through a web-interface and also some more privileged persons need to see these numbers, so I also need to make these numbers visible to the other privileged persons by the way.

I'm wondering of something like a public-key/private-key structure, but it's too much for just encrypting a phone number per person, and also there would be a problem for new users, because the previous numbers didn't encrypted with their public-keys.

So, is there any solution you might recommend to me? maybe I should to revise or update the structure of how I'm trying to do that, huh?

Answer 1

1. For maximum security against compromise, don't store the phone numbers unless you have to. Sounds like you don't have a choice in the matter.

2. Obfuscate the phone numbers prior to encrypting them.

   • A simple obfuscation would be to rearrange the numbers based upon a predefined pattern.
   • A more advanced obfuscation would be to salt the number and then obfuscate. You would need to store this salt along with the number.
   • An even more advanced approach would be to generate the salt number based upon other characteristics of the user's data.

3. Create the obfuscation and salting routines in code outside of the database. A stored procedure might be faster, but the stored procedure is potentially included with the compromised database. External routines bypass that issue to some degree, and would require an additional degree of reverse engineering to find their functionality.

   • An additional benefit here is the ability to insert an additional authentication mechanism so you could conceivably prevent the DBAs from having access to the phone numbers since the only way to access the clear-text number is through the application you provide.

4. Consider using the native encryption capabilities of the database as it should simplify creating the access hierarchy that you mentioned.

I can't say I would recommend all of the public / private key pair combinations that you're suggesting. The overhead in maintaining that will be too much. It will also complicate the access hierarchy that you want.

Answer 2

So, you have a database backing a web application. The web application (and other side applications) need to have access to a phone number.

I am assuming that you have sufficient security in the web application side to prevent people from getting data they shouldn't have.

Your concern is that if someone with sufficient access (either proper access or ill gotten) looks at the database, you don't want that person to be able to see the phone numbers in the clear.

Public/private is probably overkill and unnecessary. Someone that has access to the web program doing the insertion and retrieval of the phone number will also be able to do retrieval and decoding.

I would instead look at doing something along the lines of symmetric encryption where there is just one key. The web app uses it to encrypt before putting in the database and decrypt when it is needed for display. Other apps would also use the same key.

If the key is compromised, you decrypt all the data and re-encrypt it with a new key.

I would strongly encourage you to consider adding additional 'junk' to the data so that it isn't trivially decoded (if you have 10 characters being encoded and it is known that they are all characters that match [2-9][0-9]{9}, the cryptanalysis of the data could be done rather quickly in the event the data is compromised.