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.
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
