On Thu, Aug 12, 2010 at 10:00 AM, tedd <t...@sperling.com> wrote:
> At 8:09 PM -0400 8/11/10, Bastien Koert wrote:
>> From my experience, I'd have to say that it would be a real tough go
>> to crack that. If there was a weak point in the scheme is that your
>> end result pattern ( the ssn ) is defined with a pair of constants,
>> the hyphens. In our scheme we remove the dashes and just provide a
>> mask for display. We also keep a unique key with each ssn, the record
>> number for extra security.
> The SS numbers can be stored in any format (with/without hyphens, reversed,
> transposed, predetermined mixing, whatever).
> Of course, there can be another field where a unique key is kept, but I'm
> not sure how that might improve security.

Just adds another layer to it.

>> Where to keep it is tougher, OWASP suggests that the keys be stored on
>> another non web facing server, with a locked down filesystem. That
>> would be best if you have the hardware available.
> So that I understand, you are talking about two web sites where one
> (domain1.com) would contain/run the scripts and the other (domain2.com)
> contained the keys.
> It would work like so:
> When the script launches in domain1.com, the script would ask (after
> authorization) domain2.com for the keys, which are kept in a locked
> directory. After which the Encryption/Decryption scheme would work.
> Is that it?


>> One other option here is to load the keys into ram on server start up and
>> never have
>> them physically on the machine.
> I'm not sure as to how to make that work. But I assume that it requires a
> dedicated server, right?

Yes, you would need a non web facing machine

> Cheers,
> tedd
> --
> -------
> http://sperling.com/



Cat, the other other white meat

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to