Prev: Storing Social Security Number WAS: Encryption/Decryption Question
Next: imagettftext Angle Problem
From: tedd on 12 Aug 2010 10:23
At 2:59 PM +0100 8/12/10, Richard Quadling wrote:
>On 12 August 2010 14:45, tedd <tedd(a)sperling.com> wrote:
>> At 5:30 PM -0700 8/11/10, Daevid Vincent wrote:
>>>
>>> > -----Original Message-----
>>>>
>>>> 2. Were told it was a social security number
>>>> (i.e., in the form of 123-45-6789).
>>>
>>> Stop.
>>>
>>> Why are you even contemplating storing SS# ??
>
>Why hold the SSN (encrypted or otherwise). If you hold it encrypted,
>then the keys have to exist somewhere and that will cost you
>something.
>
>Why not hold a non reversible hash? That way you can't determine the
>SSN, but someone posing as the SSN holder presents their SSN, you run
>it through the same hash routine and compare the hashes. If they
>match, then the SSN is valid. If not, then not.
>
>Don't store the SSN would be my way.
>
>The same way you don't store passwords using a reversible technology.
>
>Richard Quadling.

Richard:

That would work (and does work) for storing things like passwords. I
have routines where users logon and enters their password where I
md5() it and store the hash in a database. The next time the user
logs on, the script again runs the password through the md5() and
compares results with the database. If there is a match, then access
is provided. If not, then it fails. All of this without me (the
database) knowing what the password actually was.

However in this case, the authorized users of database must be able
to see the actual SS# for their processing. Seeing a md(), or any
other hash, would not serve the purpose of having the numbers in the
database.

Cheers,

tedd


--
-------
http://sperling.com/
 | 
Pages: 1
Prev: Storing Social Security Number WAS: Encryption/Decryption Question
Next: imagettftext Angle Problem