[Feature Request] Provide guidance to users on complexity requirements of OPENSEARCH_INITIAL_ADMIN_PASSWORD before software installation

[williamtrelawny]

Is your feature request related to a problem? Please describe

ref: https://github.com/opensearch-project/documentation-website/pull/7126#issuecomment-2103336425

The only time users are told their OPENSEARCH_INITIAL_ADMIN_PASSWORD is too weak is after they install and launch Opensearch, and only in the server log.

Even then, the guidance users are given isn't accurate:

Password Changeme!23 failed validation: "Weak password". Please re-try with a minimum 8 character password and must contain at least one uppercase letter, one lowercase letter, one digit, and one special character that is strong. Password strength can be tested here: https://lowe.github.io/tryzxcvbn

As you can see, my supplied password Changeme!23 meets all the stated complexity requirements, yet it still is disallowed.

Describe the solution you'd like

I'd like to see the complexity requirements completed lifted actually, at least for single-node deployments, which most lab/testing/demo deployments are. I understand the reason for requiring secure passwords, but when deploying Opensearch for lab/testing/demo purposes this requires more effort than really necessary.

When enforcing complexity requirements though, the actual requirements should be clearly listed in the stdout printed after installation. OR, change the complexity checks in code to match what's printed in the server.log when a "weak" password is used.

Related component

Other

Describe alternatives you've considered

No response

Additional context

No response

[reta]

@williamtrelawny this belongs to security plugin, could you please open an issue there: https://github.com/opensearch-project/security/issues , thank you.

[dblock]

Moved to the security repo.

[DarshitChanpura]

@williamtrelawny It gave a low score because Changeme is a commonly used password. I tried a similar length Somerand!23 and the score was 3/4 on https://lowe.github.io/tryzxcvbn/. We consider anything below score of 3 as Weak Password. Scoring works differently on zxcvbn than just satisfying the minimum criteria. Instead, if it makes it easier, we can add a step stating something like: Do not use commonly used words like "admin" and "changeme" in the password.

[williamtrelawny]

That still seems a bit messy to me because we'd have to list off every common word/phrase NOT to use. Good to know you consider any score less than 3 weak. If you really want to use that external tool for validating password complexity, then say that passwords require a score of 3 or higher.

But I'd recommend against relying on an external tool for password complexity altogether because it results in a very disjointed user experience when installing, not to mention quite unprofessional. I can't think of another tool that requires users to validate their passwords against a 3rd party tool.

That's why I recommended removing this check entirely for single nodes, and if you must have a complexity checker then do something very basic and do it in-app, not use a 3rd party website.

Again, we as software developers can only do so much to bolster security. And it's not like this is an end user account where they should change it every so often- this is an enterprise-grade application that will be operated by experienced administrators. If they still choose to use a password like Changeme123! on a production system, then by the process of natural selection they won't be a system administrator much longer 😄

[DarshitChanpura]

We currently do not have in-house password strength validator and hence the usage of 3rd-party strength checker, zxcvbn . Check this out: https://github.com/opensearch-project/security/blob/f06557572086bd606858426123bd188c596ee0c1/src/main/java/org/opensearch/security/dlic/rest/validation/PasswordValidator.java added through this PR: https://github.com/opensearch-project/security/pull/2557

zxcvbn is a commonly used and was added for user's to check when they reset/update passwords. For demo configuration, this component was re-used to set a custom password. Since (demo-configuration) admin does not change password often, this should be relatively simple change for a better security posture (than the default password of admin supplied via internal_users.yml when using demo configuration).

The password strength validator (outside of demo configuration) uses this configured setting plugins.security.restapi.password_score_based_validation_strength to check passwords. This setting defaults to "strong" however can be configured to a lower bar.

A better option would be to allow a configuration setting to either use in-house regex comparator or the third-party zxcvbn, and leave this decision onto the user. (Should default to RegEx comparator in case neither are set)

Please let us know if you have a different suggestion that would work in the same scenario to make the check better. We will always appreciate any contributions from the community!

[derek-ho]

[Triage] Marking this as triaged since we would gladly accept a code change or documentation fix regarding this. @williamtrelawny can you provide the distribution that you are using to help us further narrow down this issue?

[williamtrelawny]

@derek-ho I'm using Debian 12 in this instance