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 t
> -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 sear
> -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
>
&g
On Thu, 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'
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
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 just
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 a
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 o
On Thu, Aug 12, 2010 at 10:30 AM, tedd 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 the data.
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 lev
At 2:59 PM +0100 8/12/10, Richard Quadling wrote:
On 12 August 2010 14:45, 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 contempla
On 12 August 2010 14:45, 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# ??
Why hold the
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# ??
>
>
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
14 matches
Mail list logo
