Improve error messages when password doesn't meet policy requirements.

[TonyLovesDevOps]

Preflight Checklist

• I have completed all Troubleshooting Steps.
• I'm on the latest version of Directus.
• There's no other issue that already describes my problem.

Describe the Bug

Right now, when a user offers a password that doesn't meet the password complexity requirements, the error messages returned to the user could be more helpful.

For example, when accepting an invite, the user sees an Unexpected Error:

And when resetting a password, they receive the much better but still not super clear Value doesn't have the correct format:

To Reproduce

Scenario 1: Accept invite

1. Choose an Auth Password Policy other than None on the /admin/settings/project page;
2. Send an email invite to a new user;
3. Click the invite link and enter a password that doesn't meet the requirements;

Scenario 2: Reset password

1. Choose an Auth Password Policy other than None on the /admin/settings/project page;
2. Log in as an existing user and attempt to reset their password to a new one that doesn't meet the policy requirements.

Expected: User receives an error message stating that their password does not meet the password policy.
Actual: User receives Unexpected Error in scenario 1, and Value doesn't have the correct format in scenario 2.

In both cases, the directus logs contain messages showing Provided password doesn't match password policy -- can we return that to the user in both cases instead of the cryptic messages?

What version of Directus are you using?

v9.0.0-rc.96

What version of Node.js are you using?

v16.10.0 (from directus/directus:9.0.0-rc.96 docker image)

What database are you using?

MariaDB 10.3.23

What browser are you using?

Chrome 94.0.4606.71

What operating system are you using?

macOS

How are you deploying Directus?

Docker

[TonyLovesDevOps]

One idea around this would be to add an element to the Auth Password Policy section with an optional Custom error message or Description of policy field that could be shown to the users in this case, in addition to or instead of the Provided password doesn't match password policy message, e.g. Password must be a minimum of 20 characters in length with at least one number, one uppercase letter, and one symbol.

[azrikahar]

This was actually my concern over at #8526 (comment) 🙈

In both cases, the directus logs contain messages showing Provided password doesn't match password policy -- can we return that to the user in both cases instead of the cryptic messages?

We might need to change the exception thrown here:

directus/api/src/services/users.ts

Lines 92 to 99 in 9696212

	throw new FailedValidationException({
	message: `Provided password doesn't match password policy`,
	path: ['password'],
	type: 'custom.pattern.base',
	context: {
	value: password,
	},
	});

so that we can translate the message on the app 🤔

One idea around this would be to add an element to the Auth Password Policy section with an optional Custom error message or Description of policy field that could be shown to the users in this case,

Interesting idea!

[rijkvanzanten]

@azrikahar Adding a new "PasswordPolicyValidationException" would make the most sense to me. As for the translated message, I agree we can't just show "Password should match /(?=^.{8,}$)(?=.*\d)(?=.*[a-z])(?=.*[A-Z])(?=.*[!@#$%^&*()_+}{';'?>.<,])(?!.*\s).*$/", as nobody would understand what that means.. Just showing "Password isn't strong enough" wouldn't really help much neither.

Adding a custom message would be nice, but would still require you to explain the regex you entered again. Technically speaking, we have all the information we need in the regex itself:

/(?=^.{8,}$)(?=.*\d)(?=.*[a-z])(?=.*[A-Z])(?=.*[!@#$%^&*()_+}{';'?>.<,])(?!.*\s).*$/

Part	Description
(?=^.{8,}$)	At least 8 characters
(?=.*\d)	Needs to have a number
(?=.*[a-z])	Needs to have a lowercase character
(?=.*[A-Z])	Needs to have an uppercase character
(?=.*[!@#$%^&*()_+}{';'?>.<,])	Needs to have one of !@#$%^&*()_+}{';'?>.<,
(?!.*\s)	Can't have any spaces

I'm wondering if we could pull a regex101.com, and basically come up with a human readable description of the given regex 🤔

[inta]

Whats the idea of exluding spaces? I don't think its a good idea to limit the entropy in any way.

[rijkvanzanten]

This is just an example of how we could potentially check parts in a regex

[inta]

Really? I found this discussion because I found out Directus is refusing every passwort with a space in it if the rule is set to strong. That was unexpected for me.

[paescuj]

Really? I found this discussion because I found out Directus is refusing every passwort with a space in it if the rule is set to strong. That was unexpected for me.

Well, the RegEx from above indeed corresponds to the one from the "strong" policy in Directus and I do think it's arguable whether spaces should be allowed, too.
However, the discussion here was about a different topic, so it would be better to open up a separate one for this concern.

[TonyLovesDevOps]

I'm wondering if we could pull a regex101.com, and basically come up with a human readable description of the given regex 🤔

🧐 regex101.com does have a public API that could even be used to create a regex and then point the user to a URL that would include the Explanation -- though the verbosity of the explanation is probably almost as impenetrable as a regex to a normal user (not to mention creating a dependency on a third-party service with zero availability guarantees). I took a quick look for libraries that turn a regex into something human readable and didn't see anything promising at first glance, and whatever regex101 uses is not open source.

This is where I thought a custom error message might come in handy... if you're the admin setting the password policy, you're going to want to communicate it to your users somehow, unless you're a BOFH in which case Unexpected Error seems a perfect way to punish your (l)users. 😈

[rijkvanzanten]

🧐 regex101.com does have a public API that could even be used to create a regex and then point the user to a URL that would include the Explanation -- though the verbosity of the explanation is probably almost as impenetrable as a regex to a normal user (not to mention creating a dependency on a third-party service with zero availability guarantees).

Yeah I wouldn't want to actually point to regex101, I meant that it would be nice if we could do a similar trick where we auto-generate a human readable explanation 🙂

[azrikahar]

Adding a new "PasswordPolicyValidationException" would make the most sense to me.

@rijkvanzanten Yea that's what I had in mind as well. Might be the "MVP" approach in this case.

I'm wondering if we could pull a regex101.com, and basically come up with a human readable description of the given regex

That's super interesting! But it is uncharted territory for me 😄 Maybe we can somehow do something with the AST we get after using regexp-tree?

I've also stumbled upon this site: https://regexper.com/. The railroad diagram approach somewhat make things clearer from a technical perspective, but I also understand that this is no where near understandable for non-technical end users.

[joselcvarela]

I keep questioning myself why do websites require to have special characters, uppercase, lowercase, numbers for passwords.
If the image below tells the truth we could only ask user to put a long password.
For example, I have some accounts on Google using a long string all lowercase.
On this cases, we could suggest users to put a sentence from a lyrics they love 😀

About the regex, maybe we could use named groups somehow: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_Expressions/Groups_and_Ranges#using_named_groups

[paescuj]

Might be interesting as well: https://github.com/VerbalExpressions/JSVerbalExpressions

[benhaynes]

All good stuff! I'd like to add the recommendation from @TonyLovesDevOps — let's add a Password Policy Error Message field (STRING) that allows entering a custom message. The default value here should be:

Doesn't fulfill password policy requirements

The input should be full width, and below the other two fields.

[paescuj]

All good stuff! I'd like to add the recommendation from @TonyLovesDevOps — let's add a Password Policy Error Message field (STRING) that allows entering a custom message. The default value here should be:

Doesn't fulfill password policy requirements

The input should be full width, and below the other two fields.

While a message like this is way better than Unexcepted Error, it still isn't very helpful for users as they don't know how to full-fill the requirements.
It would be awesome to have an interface to define policies which are then automatically turned into human readable messages 😄
I also stumbled upon the follwing libraries which might be helpful:

• https://github.com/auth0/password-sheriff
• https://github.com/kamronbatman/joi-password-complexity

[benhaynes]

While a message like this is way better than Unexcepted Error, it still isn't very helpful for users as they don't know how to full-fill the requirements.

Why doesn't this direction solve for that? The placeholder value is only because it's not dynamic... but the admin would change it to a specific that matches the Policy/RegEx. So if they make some crazy policy, they can say:

Must contain 3 multi-case letters, 4 numbers, 6 special characters, and an emoji.

To me, this adds the most freedom and avoids us building/integrating/maintaining a complex regex decoder.

[paescuj]

While a message like this is way better than Unexcepted Error, it still isn't very helpful for users as they don't know how to full-fill the requirements.

Why doesn't this direction solve for that? The placeholder value is only because it's not dynamic... but the admin would change it to a specific that matches the Policy/RegEx. So if they make some crazy policy, they can say:

Must contain 3 multi-case letters, 4 numbers, 6 special characters, and an emoji.

To me, this adds the most freedom and avoids us building/integrating/maintaining a complex regex decoder.

True, should have read @TonyLovesDevOps proposal more carefully 🙈👍

[rijkvanzanten]

One thing to keep in mind with the custom error message is i18n... 😬

[benhaynes]

True, but that will be a bigger task with the "string" approach... as we don't support it for the "Public Note" either.

[aidenfoxx]

You could also just break down the components of password complexity into configurable options in the UI. Realistically that should serve 90% of users, and you have fixed parameters to return a message by. E.g:

• Minimum length input
• Require numeric checkbox
• Require uppercase checkbox
• Require symbol checkbox

That would also allow for a nicer error interface à la:

[TonyLovesDevOps]

@aidenfoxx @rijkvanzanten @paescuj do any of you have code brewing for this, or an idea of when you might spend time on it? Alternatively, I could take a stab at the Password Policy Error Message implementation, which isn't as fancy as some of the other cool ideas posted here, but would definitely work for my purposes.

[paescuj]

@TonyLovesDevOps Not from my side... Would love to see a PR from your side 😃❤️‍🔥

[rijkvanzanten]

Likewise, I don't have anything in works at the moment 👍🏻

[aidenfoxx]

Nothing from me. Go for it! 👍 😄

[TonyLovesDevOps]

Cool, I opened a PR for this. I'd value reviews/input on the PR, especially if someone knows of a boilerplate unit test I can copy as a starting point for this - I didn't see any existing tests that set up an auth_password_policy scenario, and I don't have time right now to bang my head against an unfamiliar unit testing framework. 😭

Here's what it looks like with a custom message when accepting an invite / changing a password:

[TonyLovesDevOps]

So #8946 appears to be in PR purgatory. Is there anything I can do to help get it merged?

I'd happily support a better alternative implementation but we'll soon need to consider the regrettable decision to fork so that our users have a better experience when accepting an email invite, as almost no one meets our policy requirements on the first try.

[rijkvanzanten]

Heya! Thank you for taking the time to submit this request!

It has been over 90 days, and this discussion has not received at least 15 votes from the community. This means that we don't feel like there's enough community interest to warrant further R&D into this topic at this time. 🧊

This request will now be closed to keep our discussions tidy. Please reach out if you have any questions!

For more information, see our Feature Request Process.

[anantakrishna]

In this case I'd consider this to be a bug report rather than a feature request…

[abernh]

For everybody stuck with the ambiguous error message (e.g. on Directus Cloud without options to fix it) I posted a CSS-only hack here

#13896 (comment)

[thorstenvonberswordt]

This all is an absolutely valid complaint (just as the: wrong payload message on double password creation -> discussion), and should be fixed since it seems reasonably simpel to do so! I too stumbled quite fast across this problem in our evaluation of directus. And for sure if you want to market this as headless cms those kind of things got to be in order since not everybody wants to program an API interface just to be able to add users ....
love the css hack from @abernh but this should be necessary!