In keystone stable/Havana release, password for a user can be set during user creation process. Now if a user initially do a sha512 hash of his password and sent it to the keystone server over the wire, then hash_password method of keystone/common/utils.py
def hash_password(password):
~ | """Hash a password. Hard."""
~ | password_utf8 = trunc_password(password).encode('utf-8')
~ | if passlib.hash.sha512_crypt.identify(password_utf8):
~ | return password_utf8
~ | h = passlib.hash.sha512_crypt.encrypt(password_utf8,
~ | rounds=CONF.crypt_strength)
~ | return h
will not do any hashing, or it directly store the password in DB.
However, during authentication, the user needs to provide the clear text password for authentication because during authentication it always does sha512 over the password field (it does not check the password is already hashed)
def check_password(password, hashed):
""Check that a plaintext password matches hashed.
hashpw returns the salt value concatenated with the actual hash value.
It extracts the actual salt if this value is then passed as the salt.
"""
if password is None or hashed is None:
return False
password_utf8 = trunc_password(password).encode('utf-8')
return passlib.hash.sha512_crypt.verify(password_utf8, hashed)
Now in this case,
1) user chooses a password which is similar to a sha512 output, now keystone thinks it is already hashed, so it will store it as it is. User provides the sha512 during authentication but he cannot login this time cause now the password is hashed before matching.
There should be consistency for both password creation and verification process.
As this is not a vulnerability but a bug with some security implication, there is no need to keep this private.