Open Stack

In my proposed fix I took the stance that we should always be treating
user input as untrusted.  Just hash it and move on.

The code that checked if the password was already hash seemed to have
been written so that a migration process could use the same API code to
move users around.

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1279849

Title:
  keystone password creation and verification mismatch

Status in OpenStack Identity (Keystone):
  In Progress

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1279849/+subscriptions