Joe, something I've explored doing (wrote a little paper on it, but never
implemented it) was to have a pair of values for sensitive fields. One is
the encrypted value (socialSecurityNumber) and the other is a version
(socialSecurityNumberVersion). The version field maps to different keys
used to encrypt the main field. This allows for the keys to be changed (due
to an employee leaving or perhaps you have a 3 month mandate for key
changes) while still allowing you to read the old values. The key file
should be kept on the disk and protected by Unix file permissions so others
can't read it easily.
I'm not sure if I made sense, but I've you'd like, I can dig up my little
paper to send you (it might be more helpful). Just tell me the formats you
can read (right now it is a Google Doc).
mrg
On Thu, Feb 5, 2009 at 11:01 PM, Joe Baldwin <jfbaldwi..arthlink.net>wrote:
> These are all good points. I can do it either way as far as the business
> rules go. I was just looking for some suggestions as to best practices.
> The downside to using the database-managed encryption, is that it makes the
> Cayenne code pretty messy (unless of course that I have missed some
> Utility/Convenience method that deals with applying MySQL functions to
> fetched data).
>
> I can brute-force this, as I mentioned earlier, by making the conversions
> via Cayenne select queries and the #result directives pattern. My
> implementation turned out to be kind of messy and so I was thinking there
> has to be a better way.
>
This archive was generated by hypermail 2.0.0 : Fri Feb 06 2009 - 09:36:06 EST