The recent credit card number breach on the internet has some important lessons for all of us in the database application creation arena
First, don't store any personal data (e.g. Credit Card Numbers, Social Security Numbers, Birthdates, etc) in regular text. If possible, pass the buck. Let someone else (e.g. PayPal) store this information and take the risk if possible.
Second, IF you do store personal data , see if the First solution is not better. Otherwise, encrypt those fields. Someone without the decryption algorithm is immediately locked out of the data.
Then
First, don't store any personal data (e.g. Credit Card Numbers, Social Security Numbers, Birthdates, etc) in regular text. If possible, pass the buck. Let someone else (e.g. PayPal) store this information and take the risk if possible.
Second, IF you do store personal data , see if the First solution is not better. Otherwise, encrypt those fields. Someone without the decryption algorithm is immediately locked out of the data.
Then
- If an application user needs to verify, show a portion (e.g last 4 digits).
- If an application user needs to change it to a new value, just overwrite it without viewing the old.
- If an application user needs to view it, Log the viewing, and show it only while he is physically in the field. Leave the field or revert back to encrypted view after timeout of no more than 5 minutes
- If an application user never needs to see it and the application itself only needs to verify it by comparing it to something previously entered, then encrypt the entered and compared to stored encrypted original entered value. Using an MD5 hash or similar will pretty much guarantee that no user without the original value will be able to generate the same comparison value. This is absolutely the best way