Re: Encrypted Fields

From: Joe Baldwin (jfbaldwi..arthlink.net)
Date: Thu Feb 05 2009 - 23:01:20 EST

  • Next message: Michael Gentry: "Re: Encrypted Fields"

    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.

    Perhaps the Java-domain solution is the easiest.

    On Feb 5, 2009, at 6:26 PM, Aristedes Maniatis wrote:

    >
    > On 06/02/2009, at 9:36 AM, Joe Baldwin wrote:
    >
    >> What design (or pattern) is best for fields that are to be encrypted?
    >>
    >> MySQL has quite a few simple functions that can be used to encrypt
    >> data. However, when using Cayenne to fetch the data I have not
    >> found a simple solution.
    >
    > I think the answer depends on why you are encrypting data and where
    > the key will be stored to decrypt the data. Some options:
    >
    > 1. Store the key in the model and use keys hardcoded in SQL
    > templates to use mysql to d/encrypt. Anyone who got access to both
    > the database and the model would be able to decrypt all the data.
    > How secure is the model?
    >
    > 2. Do the whole thing in Java where the encryption is much closer
    > the point of data entry/view. This gives you many more options for
    > how you manage the encryption and for how long the unencrypted copy
    > exists in memory or is pushed across networks, say between the
    > application server and the database server.
    >
    > But for you, does it matter whether unencrypted data lives in memory
    > or across the network? If not, would it do instead to store the
    > database on an encrypted disk partition?
    >
    > Also ask yourself whether you might be better hashing the data
    > rather than encrypting it. For passwords, that is always a better
    > idea. For credit card numbers it still lets you detect duplicates.
    >
    >
    > Ari Maniatis
    >
    >
    > -------------------------->
    > ish
    > http://www.ish.com.au
    > Level 1, 30 Wilson Street Newtown 2042 Australia
    > phone +61 2 9550 5001 fax +61 2 9550 4001
    > GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
    >
    >



    This archive was generated by hypermail 2.0.0 : Thu Feb 05 2009 - 23:01:56 EST