yahoo-eng-team team mailing list archive

[OpenStack Infra <1901891@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.opendev.org/c/openstack/keystone/+/828595
Committed: https://opendev.org/openstack/keystone/commit/3288af579de8ee312c36fb78ac9309ce8c554827
Submitter: "Zuul (22348)"
Branch:    master

commit 3288af579de8ee312c36fb78ac9309ce8c554827
Author: Dave Wilde (d34dh0r53) <dwilde@xxxxxxxxxx>
Date:   Wed Feb 9 11:28:59 2022 -0600

    Force algo specific maximum length
    
    The bcrypt algorithm that we use for password hashing silently
    length limits the size of the password that is hashed giving the
    user a false sense of security [0].  This patch adds a check
    in the verify_length_and_trunc_password function for the hash in
    use and updates the max_length accordingly, this will override
    the configured value and log a warning if the password is truncated.
    
    [0]: https://passlib.readthedocs.io/en/stable/lib/passlib.hash.bcrypt.html#security-issues
    
    Closes-bug: #1901891
    Change-Id: I8d0bb2438b23227b5a66b94af6f8e198084fcd8d


** Changed in: keystone
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1901891

Title:
  Issues regarding application credentials

Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  While looking into the application credential API we came across
  several issues. Since they are all closely related I will file them
  under this issue:

  - No secret strength requirements. To configure a password strength
  requirement for users, one can use `password_regex`. However, this is
  not possible for application credentials, which makes it possible to
  create a credentials with the secret 'a':

  $ openstack application credential create test-secret-strength --secret a
  +--------------+----------------------------------+
  | Field        | Value                            |
  +--------------+----------------------------------+
  | description  | None                             |
  | expires_at   | None                             |
  | id           | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
  | name         | test-secret-strength             |
  | project_id   | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
  | roles        | member reader                    |
  | secret       | a                                |
  | system       | None                             |
  | unrestricted | False                            |
  | user_id      | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
  +--------------+----------------------------------+

  To attack this, you'd still need to know the ID, but combined with
  https://bugs.launchpad.net/keystone/+bug/1901207 the impact of this
  issue is increased.

  - No lockout feature. For normal login, the settings
  `lockout_failure_attempts` and `lockout_duration` are used. These do
  not affect the application credential API. This increases the attack
  surface unnecessarily in my opinion. Combined with weak secrets and
  https://bugs.launchpad.net/keystone/+bug/1901207 the probability of a
  successful attack is increased.

  - Only part of secret is verified. It looks like only the first 72
  characters of the secret of an application credential are used to
  verify it. Characters after that are not used in the verification. The
  default length of a secret seems to be 86 characters. Even though
  brute forcing 72 characters is still pretty impossible, this doesn't
  sound like intended behaviour to me.

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