At 3:48 AM -0400 8/12/10, Adam Richardson wrote:
-- snip excellent points --
Of note, SS#'s are a special piece of data, not only because of their power,
but because of their lifetime (normally as long as the individual lives.)
This is very different from a credit card which gets updated every 5 years
or so, and is easily changed if needed. You have to ask yourself if the
encryption/security scheme can be counted on to protect this data many years
Agreed and understood.
In summary, I wouldn't use this scheme for storing SS#'s in a large DB, as
it would keep me awake at night. If the DB was ever compromised, I would
NOT HAVE CONFIDENCE IN THE ENCRYPTION'S ABILITY TO PROTECT THE SS#'s. The
probabilities are just to poor when compared to other, better
What do you recommend? Do you have code/reference?
However, if this is just a "Tedd" special for storing a few SS#'s on your
home computer/network, I wouldn't worry too much because 1) it's your SS#,
not mine, and more importantly 2) such a small set of SS#'s wouldn't be
analyzed because it wouldn't merit the processing power/time (unless you get
really, really rich really really quick ;)
This isn't a "Tedd's" special for storing my SS#'s on my own
computer, but rather an honest attempt to better understand and
implement a prudent Encryption/Decryption scheme.
Not that you said otherwise, but I am capable of understanding how
these things work. My problem is that I am not current on what
practice is best. It seems to me that things change so fast that when
you become to rely on one solution, it goes out of date and is
replaced with something else.
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php