Allow password minimum and maximum rules to be the same value

[mooreds]

Allow password minimum and maximum rules to be the same value

Problem

Right now, you can set up password minimum and maximum rule lengths on a tenant. However, the maximum must be greater than the minimum value. If you want to require a password to be exactly 20 characters, then you can't enforce that using these password rules. In the admin UI, you get an error message if you try to set up an exact character count. (I didn't try with the API.)

From reading the code, the min value checks that the character count is greater than or equal to the value, and the max value checks that it is less than or equal to the value.

Solution

Allow the min and max values to be the same.

Alternatives/workarounds

Client side validation? Set the min to 20 and the max to 21?

Additional context

This came up on a customer kickoff call.

Community guidelines

All issues filed in this repository must abide by the FusionAuth community guidelines.

How to vote

Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.

[robotdan]

Probably no reason not to allow this, but seems really unlikely that anyone would have a legit reason to require a password length of exactly n characters.

In our default themed pages, we have the option to show the user the password constraints during self-service registration or during a password change so the user knows the rules.

It would be a really bad idea to set set these two values equal, and then tell the world that your password requirements limit the password to exactly n characters. This would make it much simpler for a would be attacker to try and brute force your password.

We generally don't want to advertise the exact length of anyone's password. 😎

This is a super easy change, but because it doesn't seem like there is a real use case here, I would hesitate to prioritize this effort.

[mooreds]

Is there a material difference between setting it to 19 and 20 (for the min and max values) and only 20? (For example?)

[robotdan]

Is there a material difference between setting it to 19 and 20 (for the min and max values) and only 20? (For example?)

No probably not. But that would also be a poor configuration. So we could go the other way and require a delta between the min and max values to encourage more secure configurations. But that would be a breaking API change because we have not done that in the past, and it is plausible that whatever delta we choose would be violated by some existing configuration.

In practice, I see little reason to ever reduce the maximum length below the maximum allowed value. The maximum will be 256 for most algorithms, and 50 for Bcrypt.

Did client have a use case for this, or was it just an observation?

[mooreds]

Did client have a use case for this, or was it just an observation?

Client was sending passcodes over SMS and they were limited to exactly N characters.

Not a big deal, since they'd only send N characters and can enforce it on the front end (via JS on themes) but they were looking to lock things down on the back end as well.

[robotdan]

Client was sending passcodes over SMS and they were limited to exactly N characters.

Ok. Perhaps we are thinking of different things.

Is the customer thinking of the configuration for SMS one time codes? I hope nobody is sending their users plain text passwords over SMS.

[mooreds]

Ooh, good point. I may have misspoken. I reviewed notes and think it was a OTP, which is configured in an entirely different way. My bad. I think we can close this issue out.