yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #91416
[Bug 1901891] Re: Issues regarding application credentials
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