Open Stack

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
>> now.
> [...]
>
> 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:

https://review.openstack.org/#/c/61445/

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.