Versions (relevant - OpenSearch/Dashboard/Server OS/Browser):
OpenSearch 2.8.0 (deployed via OpenSearch Helm Chart version 2.13.0)
Describe the issue:
I was surprised when my existing script to deploy OpenSearch using the official Helm chart failed. I eventually tracked the problem down to a failing curl command that creates a user using the security API. That curl command failed because the password I was using was considered “weak”. And, in the OpenSearch 2.8.0 documentation, I see there is new content referring to the use of the zxcvbn library and how it allows us to define a policy that “emphasizes a password complexity rather than it capacity to meet traditional criteria such as uppercase keys, numerals, and special characters.” That sounds like it could be very useful. However, enabling this feature seems like a breaking change to me since it broke my existing process. That would be Concern #1.
Concern #2 is that the documentation doesn’t appear to include information on how to disable this functionality. It mentions two properties (plugins.security.restapi.password.min_length and plugins.security.restapi.password_score_based_validation_strength) and how they can be set to adjust the length and required “strength”. But it doesn’t provide values to disable either/both of those settings.
My opensearch.yml file has neither of those keys set and yet the feature is working. I’ve looked at the Helm chart values.yml file and it also does not explicitly set either of these values. So, I’m not inheriting some default settings from the Helm chart. That seems to indicate these properties are enabled by default and set to some values but it isn’t clear what those values are. I guess that would be Concern #3.
Since the zxcvbn library uses its own criteria (based on commonly used passwords, English names, Wikipedia entries, etc.) it is difficult to know what to tell our users is acceptable. We could point them to the project’s GitHub repo and suggest they peruse the list of 30,000+ forbidden passwords but that seems unreasonable. We create a small number of users (via API) during our installation process after the user has provided passwords to us. Giving them guidance on what is acceptable or not would be helpful. At this point, it appears that the only way to validate a password is to attempt to use it. Let’s call that Concern #4.
It also seems this new feature is an alternative (or maybe a replacement) for existing functionality that allows us to define password validation that follows the traditional approach (i.e. requiring some combination of characters of different classes). But the documentation doesn’t indicate that the earlier approach is deprecated. So, if that is the case, I guess that would be Concern #5.
Concerns:
- Unannounced Breaking Change
- No documented way to disable this new functionality
- Enabled by default outside of the opensearch.yml mechanism with unknown default values
- No guidance to share with users on what is an acceptable/unacceptable value
- Conflicts with (or possibly meant to replace) existing password strength settings
Let me be clear: I’m not arguing against strong passwords or any particular technology. Obviously, security is important. My concern are around how this was rolled out and incomplete documentation.
Can anyone shed light on how I can disable this form of password checking?