views:

57

answers:

3

I need to store the customers' driver license # (most of the time) (or personal ID) so when they come to pick their product they can identified themselves based on their id. This is usually the way it is handled everywhere in my country (unfortunately). However, I would like to store this #'s encrypted in mysql. I now I can make use of AES_ENCRYPT, but, my question is, if I hard code the $key, then an attacker who gains access to the server can easily decrypt all of the fields having the key. How can I deal with this?

What I had in mind was to use perhaps openssl_public_encrypt and have a public and private key, but not sure how to implement it. (any good links for explanation?) maybe Asymmetric Key RSA?

I have several physical servers available that I can make use of, if needed.

Any help will be appreciated.

+4  A: 

Why do you need to encrypt these licenses asymmetrically?

  1. Validate that the user is providing a valid license.
  2. sha1 the license and save to database.
  3. When you are looking up the license, sha1 the user input and check if it matches.
troynt
agreed -- don't store the actual ID# anywhere.
jnpcl
Thats a good observation. Might be a better way to go! However, what if for some reason (unknown for me right now) we need back the number?
ashimi70
This is the recommended way - even if your server is compromised, the hacker will have no use for the hashes!
jusunlee
@ashimi The best form of privacy is when you are literally unable to divulge a user's information because you simply don't have it. Hashing is the way to go, unless you can envision a real, concrete situation where you need the license number. Don't worry about "what if".
meagar
Edit: message digest functions are not encryption functions.
Rook
A: 

The way I have achieved this in the passed is not to store the full details.

The number you require will be hashed. More-so a collection of some of the values inside the string of which has been encrypted in a way you choose.

You salt this with some relevant information about the user. Say the users email or an ID number you've generated.

When the user validates say '12345678' you've made a hash of 1458 to something like '$£%$dfovm$£$' of which is coupled with part of the email.

That way, if someone can gain access they can never retrieve all the users number. Additionally, if they were to somehow piece together the decrypted version of the string - it'll be a gabble of the license number and some other info.

Glycerine
A: 

Once an attacker has access to your server, they can run your code. Therefore, anything your server has to decrypt into plain text in order to use, your attacker can too. As said above, your best bet is to encrypt the ID in the same way you would a password, one way, and then encrypt the customer input and compare it, this way not even you have access to the initial IDs.

Aquarion