You could certainly change the hashing up a bit. I was going more for
concepts than anything else. You could even have separate keys and salt
(don't mix the two) or keys for encryption and random salt for hashing that
is encoded somewhere. Keep in mind if you do that, though, you'll have to
know how you hashed it (since you are storing it in the data and not the
framework). If you used MD5 one day, then switched to something else (say,
SHA-256), you would need to be aware of that so you can re-hash correctly.
And putting that in the DB might expose more information that you want (the
DB would contain the algorithm, the salt, and the hashed value). If you use
the same key/salt for the password, then indeed two identical passwords
would appear the same in the DB. I guess you have to balance your needs.
A quick and dirty (and perhaps effective) way would be to use the key file
and still have the passwordVersion field, but pass an additional "random"
salt into the hash to be used as part of the key. The obvious salt would be
the username. The SF could then, based upon the key version, inject the
salt/username into the key. Say, version 1 injects the salt into the key at
position 12. Version 2 injects it at position 5. Version 3 reverses the
salt and injects it at position 8. Etc. Go wild. :-)
Thanks again!
mrg
On Tue, Feb 10, 2009 at 10:39 AM, Mike Kienenberger <mkienen..mail.com>wrote:
> Ok. I see hashing code is encapsulated in the entity now. I was too
> used to my own ways of doing things where setPassword() always takes
> an encryption value.
>
> As for the randomness, I guess it's more correct to say variation.
> The varying part isn't hidden, it's part of the key as you said. I
> believe the reason that this is done is so that two equal plain-text
> values do not result in two equal encrypted values. Thus, "breaking"
> the encryption on one value doesn't automatically give you any other
> values. The variation would be stored as part of the encrypted
> value. But this would/could all be encapsulated in the framework and
> hidden from the application code and the returned encrypted value
> would take that into account, so I guess it's a moot point :-)
>
> The idea of versioning and an IN query to search on an encrypted field
> are new ideas that I plan to use in my next system. Thanks!
>
> On Tue, Feb 10, 2009 at 10:25 AM, Michael Gentry <mgentr..asslight.net>
> wrote:
> > Hi Mike, thanks for looking through it. The code example is correct:
> > user.setPassword(plainTextPassword);
> >
> > 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.
> >
> > Thanks!
> >
> > mrg
> >
> >
> > On Tue, Feb 10, 2009 at 10:03 AM, Mike Kienenberger <mkienen..mail.com
> >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 <mgentr..asslight.net>
> >> 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.
> >> >
> >> > http://people.apache.org/~mgentry/Security_Manifesto.pdf
> >> >
> >> >
> >> > mrg
> >> >
> >>
> >
>
This archive was generated by hypermail 2.0.0 : Tue Feb 10 2009 - 11:02:20 EST