[openstack-dev] Keystone Hashing MD5 to SHA256
ayoung at redhat.com
Tue Jan 7 17:01:05 UTC 2014
On 01/06/2014 01:10 PM, Jeremy Stanley wrote:
> On 2014-01-06 10:19:39 -0500 (-0500), Adam Young wrote:
>> If it were as easy as just replaceing hteh hash algorithm, we
>> would have done it a year + ago. I'm guessing you figured that by
> With the lack of In-Reply-To header and not finding any previous
> messages to the list in the past few months with a similar subject
> line, I'm lacking some context (so forgive me if I'm off the mark).
> If the goal is to thwart offline brute-forcing of the hashed data,
> shouldn't we be talking about switching away from a plain hash to a
> key derivation function anyway (PBKDF2, bcrypt, scrypt, et cetera)?
> MD5 is still resistant to preimage and second preimage attacks as
> far as I've seen, and SHA256 doesn't take too many orders of
> magnitude more operations to calculate than MD5.
Sorry to all for the cryptic (ha) nature of this mail. It was in
response to an expired code review:
But I thought would benefit from a larger audience.
Note that the Hashes in question are not vulnerable to many of the
attecks, as they are used primarily on very strict sets of data (the
keystone tokens) and only between the keystone clients and servers. It
is not possible to create an arbitrary token, hash it, and have that at
all usable in Keystone. Which is why MD5 has not been deemed to be a
problem for us.
I like the Idea of prefixing the hashes with the algorithm, but we still
need a way to integrate that in. A specific Keystone server will only
use one Hash alrgorithm, since it is useing the Hash as the unique ID
for a database lookup. Thus, in order for the clients and server to be
in sync, they need a way to agree on the hash algorithm. Identifying it
in the hash is probably too late for most uses.
More information about the OpenStack-dev