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# ??
Daevid et al:
Why? Because my client wants to store SS numbers on their
On Thu, 2010-08-12 at 09:45 -0400, tedd 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# ??
Daevid et al:
On 12 August 2010 14:45, tedd t...@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
At 2:59 PM +0100 8/12/10, Richard Quadling wrote:
On 12 August 2010 14:45, tedd t...@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
At 2:51 PM +0100 8/12/10, Ashley Sheridan wrote:
If you are storing the data in a DB, then I'd consider using
different levels of access to that via different DB users, which
should offer an extra layer of security in protecting the data.
Of course, the routines I'm writing provide several
On Thu, Aug 12, 2010 at 10:30 AM, tedd t...@sperling.com wrote:
At 2:51 PM +0100 8/12/10, Ashley Sheridan wrote:
If you are storing the data in a DB, then I'd consider using different
levels of access to that via different DB users, which should offer an extra
layer of security in protecting
At 10:56 AM -0400 8/12/10, Bastien Koert wrote:
However, the data must be stored in an encrypted format and it must be
transmitted via SSL. We do it that way (taking both a hash for
searching for the ssn and the encrypted form) and haven't had any
issues as yet.
The data will be encrypted and
On Aug 12, 2010, at 11:32 AM, tedd wrote:
At 10:56 AM -0400 8/12/10, Bastien Koert wrote:
However, the data must be stored in an encrypted format and it must be
transmitted via SSL. We do it that way (taking both a hash for
searching for the ssn and the encrypted form) and haven't had any
At 11:39 AM -0400 8/12/10, Joshua Kehn wrote:
Would one option be to have a table of unencrypted SSN's with an
encrypted id for the user. So you could search the SSN's and then
connect them, however if the table was dumped you wouldn't be able
to link it directly to the person (as it would
On Aug 12, 2010, at 11:55 AM, tedd wrote:
At 11:39 AM -0400 8/12/10, Joshua Kehn wrote:
Would one option be to have a table of unencrypted SSN's with an encrypted
id for the user. So you could search the SSN's and then connect them,
however if the table was dumped you wouldn't be able to
On Thu, Aug 12, 2010 at 11:32 AM, tedd t...@sperling.com wrote:
At 10:56 AM -0400 8/12/10, Bastien Koert wrote:
However, the data must be stored in an encrypted format and it must be
transmitted via SSL. We do it that way (taking both a hash for
searching for the ssn and the encrypted form)
-Original Message-
From: tedd [mailto:t...@sperling.com]
Sent: Thursday, August 12, 2010 7:30 AM
To: a...@ashleysheridan.co.uk
Cc: php-general@lists.php.net
Subject: RE: [PHP] Storing Social Security Number WAS:
Encryption/Decryption Question
At 2:51 PM +0100 8/12/10, Ashley
-Original Message-
From: tedd [mailto:t...@sperling.com]
Sent: Thursday, August 12, 2010 8:32 AM
To: Bastien Koert
Cc: php-general@lists.php.net
Subject: Re: [PHP] Storing Social Security Number WAS:
Encryption/Decryption Question
For searching standard fields, it's a piece
I have an idea.
First create a master key that the ssn ar encrypted with.
Store the master key encrypted with a key accessible by users (mksk).
Every user stores the key (mksk) to decrypt the (master key) and the mksk
should be ecrypted with there password as key.
And when a new user is created
14 matches
Mail list logo
