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 - 10:40:09 EST