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 |
+--------------+----------------------------------+
- 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.
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 ------- -+----- ------- ------- ------- ------- -+ ------- -+----- ------- ------- ------- ------- -+ xxxxxxxxxxxxxxx xx | strength | xxxxxxxxxxxxxxx xx | xxxxxxxxxxxxxxx xx | ------- -+----- ------- ------- ------- ------- -+
+------
| Field | Value |
+------
| description | None |
| expires_at | None |
| id | xxxxxxxxxxxxxxx
| name | test-secret-
| project_id | xxxxxxxxxxxxxxx
| roles | member reader |
| secret | a |
| system | None |
| unrestricted | False |
| user_id | xxxxxxxxxxxxxxx
+------
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.