cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Gentry <>
Subject Re: Encrypted Fields
Date Tue, 10 Feb 2009 15:25:44 GMT
Hi Mike, thanks for looking through it.  The code example is correct:

The setPassword() method takes plain text and hashes it before calling the
super setter.  Client code that uses it (such as the routines to set and
change passwords) don't have to call the hash method before calling
setPassword() -- they just call it with the plain text password and let the
data object worry about hashing it.

If you repeatedly encrypt the same string with the same key, you'll get the
same encrypted value (to the best of my knowledge).  Changing the key is
what perturbs the output.  You need repeatability with encryption because
you need to be able to decrypt it.  Keeping the key secret is obviously
important which is why I was saying it should be locked down.

As for using random salt for hashes, you could certainly do that.  You'd
have to store that in the DB somewhere.  The biggest problem I see in doing
that is if someone has the DB password (even if only for read-only access)
or somehow obtains a copy of the DB, they have the random salt and the
hashed value and can do a brute-force or strategic attack on the password.
 (There are exploits coming out for MD5, for example.)  If the key/salt is
kept in a separate file that they don't have, it is much harder.



On Tue, Feb 10, 2009 at 10:03 AM, Mike Kienenberger <>wrote:

> Bug in login rehash:
> user.setPassword(plainTextPassword);
> Should be
> user.setPassword(hashedPassword);
> Also, your fetchUserBySSN() method assumes that encryption repeatedly
> returns the same value.   Is that always true?  I know that hashing
> passwords typically has a random salt to increase security, resulting
> in different hashed values for the same key.   You have to know the
> random salt in order to recreate the same hash key.  In unix
> passwords, this is done by reading the random salt off the front of
> the previous hashed value.
> On Tue, Feb 10, 2009 at 8:35 AM, Michael Gentry <>
> wrote:
> > I updated the document.  I tried to simplify the key protection stuff
> > (hopefully it makes a bit more sense) and added an example at the
> > bottom on how you might do a search and fetch using encrypted field
> > values.
> >
> >
> >
> >
> > mrg
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message