Introduce config to allow for password complexity #5727

kykyi · 2024-11-22T03:50:09Z

In relation to #5591

This PR introduces application config to allow for password complexity to be granularly managed with new validation options for:

presence of a lower case letter
presence of a upper case letter
presence of a number
presence of a special character (from a list of special characters that is configurable)

These are all false by default, and configurable like:

Devise.setup do |config|
    config.password_complexity = {
      require_upper: false,    
      require_lower: false,    
      require_digit: false,   
      require_special_character: false,
      allowed_special_characters: nil
  }
end

Note

I haven't run any linting, I couldn't find instructions on what config was used for that 😄

kykyi · 2024-11-24T23:30:35Z

Hey @nashby if I could please request a review 😄

lib/devise.rb

kykyi · 2024-12-03T09:31:29Z

Polite bump @nashby @carlosantoniodasilva 😇

datpmt · 2024-12-09T07:55:10Z

how about modify the following configurations in the initializer file as below?

config.password_complexity = {
  upper: 1,    # At least 1 uppercase letter
  lower: 2,    # At least 2 lowercase letters
  digit: 3,    # At least 3 digits
  special: 4,  # At least 4 special characters
}

kykyi · 2024-12-09T10:03:12Z

how about modify the following configurations in the initializer file as below?

config.password_complexity = {
  upper: 1,    # At least 1 uppercase letter
  lower: 2,    # At least 2 lowercase letters
  digit: 3,    # At least 3 digits
  special: 4,  # At least 4 special characters
}

Thanks @datpmt seems like an elegant solution ✅ One issue which I could see arise however could be a clash between this and password length minimums? For ex, if you set the above, but stuck with the default 8 character minimum, you couldn't satisfy all the configured preferences. I think something like this could use your nicer syntax but also be more ergonomic with the wider validation system:

config.password_complexity = {
  upper: true,    # require upper
  lower: false,    # don't require lower
  digit: true,    # require digit
  special: true,  # require special character
  special_characters: ["!", "?", "@", "\"]
}

What do you think?

datpmt · 2024-12-09T11:28:21Z

stuck with the default 8 character minimum

config.password_complexity = {
  upper: true,       # require upper
  lower: false,      # don't require lower
  digit: true,       # require digit
  # special: true,   # redundant
  special_characters: ["!", "?", "@", "\"] # empty <=> special: false
}

@kykyi Ah I see. Cool! Let do it! 👍

kykyi · 2024-12-10T00:35:57Z

@datpmt updated to use your dict style ✅

test/models/validatable_test.rb

datpmt · 2024-12-11T09:27:45Z

test/models/validatable_test.rb

+  def with_password_requirement(requirement, value)
+    # Change the password requirement and restore it after the block is executed
+    original_password_complexity= User.public_send("password_complexity")
+    original_value = original_password_complexity[requirement]


Useless assignment to variable - original_value.

test/models/validatable_test.rb

nvasilevski · 2024-12-18T17:05:52Z

Sorry for stirring the pot but I wanted to cross-post an opinion that presence of upper-cased letters, special characters and numbers has very little to do with password strength and what really contributes to the password strength is the length of the password. I'm genuinely worried that enforcing these password requirements from default will only contribute to poor user experience and potentially less secure passwords overall

More context - rails/rails#53984 (comment)

Upd: I overlooked the fact that all these requirements are disabled by default which is good. So perhaps it's still useful for applications that have to comply with regulations that are out of their control. I just don't think that setting these requirements should be encouraged

kykyi · 2024-12-18T22:01:43Z

Agreed @nvasilevski I think whilst this change pushes users to increase the entropy of their passwords, setting these and forgetting could lead devs into a false sense of security ➕

timdiggins · 2024-12-19T16:30:03Z

I agree with @nvasilevski - here's a specific argument against complexity requirements from the UK's National Cyber Security Centre: https://www.ncsc.gov.uk/collection/passwords/updating-your-approach#PasswordGuidance:UpdatingYourApproach-Donotusecomplexityrequirements

Recommend closure of the issue for Devise

fthobe · 2025-01-05T16:48:29Z

Picking up on a friendly invitation @nvasilevski given here
Mates, I would like to break some glass here.

I do not believe that what you write is wrong, the contrary, I believe some very valid points have been made. I am, as probably also you, sure that we are going towards a mixture of MFA and / or passwordless login and that's overall a good thing, but the environments around us are frequently not there yet.

The problem is the world:

password complexity / length policies are frequenty requirements to pass audits;
password complexity / length should have a reference implementation to avoid errors in implementation;
higher complexity while not scaling as well as length is still better than nothing.

I would also mention that the Password Guidance of the NCSC that you linked is not the only opinion and as much as I love the UK, this guideline is derived from NIST. The reasoning behind it was that statistics had shown that strong requirements create weaker user generated passwords:
Simply users went with "myf!stname$" instead of "some-very-s3cret-words-1n-a-$afe" as they struggled to remember too complex and to long passwords that needed to be changed frequently. Same applied to permutations "my-secretpassword$" became "my-secretpassword$$" upon frequently forced changes. Something that thanks to hashes and salts can (fortunately) not be tracked by a platform.

But all of there guidance needs to be seen in context of the remaining document that advises also:

having password managers;
having preferably time generated OTP tokens;
being hosted on a system by somebody who understands crafting secure servers and infrastructure.

I think @kykyi made a great PR covering everything from configurability to effective resolution of the issue, maybe you could give it a look with different eyes (fearing weak integrations instead of fearing false sense of security) and we add some lines into documentation to make this a better PR covering also that the entire UTF-8 character set is only as great as the password length.

I'd really appreciate a feedback from you guys on this and I really appreciate what you are doing here, just keep in mind that stuff like NIST / NCSC guidelines are forward looking and not backward looking and need to be seen in context of the entire document. In a perfect world we would all have a password manager and OTP token for every password, but well, we all have grandmothers / fathers and parents having issues remembering 5 letters, alfanumeric or not, struggling to use a password manager. Given what devise is, it should have everything on board to make an informed decision on this topic and implement it.

kykyi · 2025-01-05T21:42:38Z

Thanks for the perspective and for weighing in @fthobe 🙏 . I'll reopen and wait for a maintainer to merge/comment/close just so the issue can be resolved 😄

fthobe · 2025-01-05T21:48:16Z

Thanks for the perspective and for weighing in @fthobe 🙏 . I'll reopen and wait for a maintainer to merge/comment/close just so the issue can be resolved 😄

Actually @nvasilevski did not obligate you to close it, sometimes things need some time to get traction and sometimes topics move in waves.

Be patient, open source is neither fast nor democratic 😅

fthobe · 2025-01-07T18:07:10Z

@timdiggins Hey, I would be super interested in your oppinion on my comment :)

fthobe · 2025-01-16T08:39:53Z

Ping @nvasilevski @datpmt @timdiggins

Could you retake a look at this PR and the comments made above.

datpmt · 2025-01-16T08:51:06Z

Ping @nvasilevski @datpmt @timdiggins

Could you retake a look at this PR and the comments made above.

First of all, I completely agree that the length of a password significantly impacts its strength.

In fact, many websites and company security policies require users to apply complexity rules to their passwords. This means that web applications using Devise have a valid reason to implement password complexity as a feature. Whether to enable it or not is up to the owner’s discretion.

I believe Devise should offer this option.

fthobe · 2025-01-16T10:41:15Z

I believe Devise should offer this option.

@datpmt Is this PR for you acceptable or does it need additional work?

timdiggins · 2025-01-16T10:50:27Z

@fthobe Im not a maintainer/committee here so my 10c isn't worth so much 😀

A pragmatic response: My sense is that there isn't much maintainer involvement and devise is going into decline - there are CI-fix and bug fix PRs that have had no maintainer involvement so I don't think there's feature development will gain any traction.

fthobe · 2025-01-16T11:04:40Z

@timdiggins a lot of stuff still relies on it so we need to work with what we have.

I honestly think it's a very mature product.

Anyhow I'd really appreciate your opinion.

@carlosantoniodasilva does this PR have a shot to be integrated?

datpmt · 2025-01-16T12:28:42Z

I believe Devise should offer this option.

@datpmt Is this PR for you acceptable or does it need additional work?

I will take the time to run it locally and provide a review as soon as possible.

to be validated in :validatable with lower case, upper case, numbers, and configurable special character presence to be validated on.

…ly a special character is required

…d valid

kykyi · 2025-03-09T04:35:20Z

Hey all, I've updated the README and included an updated for \W based on your suggestion @salzig 🙏

I agree this PR won't make passwords on Devise impenetrable. But given how Devise is an out-of-the-box, batteries-included solution for auth, I think these changes set a minimum level of password complexity which (along with an increase in min password length) pushes users of Devise applications to use better passwords.

fthobe · 2025-03-09T11:21:44Z

@nashby and @carlosantoniodasilva
There has been no issue having had this much traction on devise in years (look at the reactions to the PR). It's a sought after feature, can we get this out of door somehow?

salzig · 2025-03-09T12:34:53Z

If the real intend is to increase the default security without arguing about what way of enforcing patterns would be the best, than you should support #5685. That really helps the default a lot.

And we don't have to stop argue about how we can improve even further, but that one is really the base to having a more modern default.

fthobe · 2025-03-09T22:11:48Z

If the real intend is to increase the default security without arguing about what way of enforcing patterns would be the best, than you should support #5685. That really helps the default a lot.

Man, you wouldn't believe how much I agree with you, I know this seems like a crusade. But I feel like I can be for long passwords and at the same time believe that many people due to external requirements need password policies and that we should find a default implementation for this.

…lso provide a configurable list of special chars

kykyi · 2025-03-09T22:35:49Z

lib/devise/models/validatable.rb

+        password_complexity[:allowed_special_characters]
+      end
+
+      def password_contains_special_character    


@salzig @fthobe this allows both approaches: \W and check based on configured special chars 👍

fthobe

Looks great to me @kykyi
But I'd really prefer also @salzig and @gregmolnar to look over this.

kuahyeow · 2025-03-10T05:47:50Z

The argument is that there should be a standardised approach to implementing password complexity requirements. But this will be default disabled in Devise. Why not in a separate gem ? The presence of five config options also implies there is no standardisation.

fthobe · 2025-03-10T06:27:05Z

hey @kuahyeow , thank you for participating in the discussion. As outlined above >10m Downloads of gems adding this functionality clearly indicate that the need of 30% of Devise installations is exactly this feature.

I fail to see yet one topic related argument why we can’t reduce implementation variability by adding exactly this. All I read is arguing how longer passwords are better completely missing the Problem: having Code fragmentation for such a basic Feature in one of the most sensitive parts of the rails ecosystem.

salzig · 2025-03-10T07:11:27Z

As outlined above >10m Downloads of gems adding this functionality clearly indicate that the need of 30% of Devise installations is exactly this feature.

30% is an argument for a separate Gem, not for inclusion. IMHO: only something used by ~80-90% of the users should be considered for inclusion. It's just more source code the maintainers have to work with, and there is already a lot.

kykyi · 2025-03-13T04:13:48Z

Throwing this into the ring, not by any means peer reviewed or backed by data, but since devise is kind of a roll-your-own Auth0 in some respects, I wanted to share that they define complexity like this:

None (default): at least 1 character of any type.
Low: at least 6 characters.
Fair: at least 8 characters including a lower-case letter, an upper-case letter, and a number.
Good: at least 8 characters including at least 3 of the following 4 types of characters: a lower-case letter, an upper-case letter, a number, a special character (such as !@#$%^&*).
Excellent: at least 10 characters including at least 3 of the following 4 types of characters: a lower-case letter, an upper-case letter, a number, a special character (such as !@#$%^&*). Not more than 2 identical characters in a row (for example, 111 is not allowed).

So these changes would give devise similar configurability which would be Good at minimum by their standard.

https://auth0.com/docs/authenticate/database-connections/password-strength

crespire · 2025-03-14T18:27:26Z

Putting a +1 to this, as it would have come in handy for our app, I will have to implement by hand for now.

fthobe · 2025-03-15T10:25:27Z

@josevalim @tegon @nashby There's no single response to any PR, is anybody of you still maintaining the project?

At this point wouldn't it be better to maybe hand over the reigns to more volunteers?

gregmolnar · 2025-03-15T11:28:51Z

I think there is a better way to address this problem. Having these validation options wouldn't necessary yield better passwords, I would rather suggest to use the combination of zxcvbn and pwned. I wrote a short blogpost about how they can be easily used in a Rails apps: https://greg.molnar.io/blog/validating-password-strength/

I think Devise is complicated enough on its own and doesn't need any new other dependencies, so my suggestion is to add a recommendation of those tools to the Readme, so folks can pull in the dependencies should they want.

crespire · 2025-03-17T18:01:00Z

I think there is a better way to address this problem. Having these validation options wouldn't necessary yield better passwords, I would rather suggest to use the combination of zxcvbn and pwned. I wrote a short blogpost about how they can be easily used in a Rails apps: https://greg.molnar.io/blog/validating-password-strength/

I think Devise is complicated enough on its own and doesn't need any new other dependencies, so my suggestion is to add a recommendation of those tools to the Readme, so folks can pull in the dependencies should they want.

Just my two cents, but if Devise validatable is already doing length validation, it seems to make sense to also allow the option to configure complexity, as it is part of what would determine a valid password in the context of a Devise based authentication system.

It seems a bit non-sensical to have to pull in additional dependencies if I'm using Devise validatable already.

To me, the logical outcome from your stance is to actually fully drop validatable all together, and if people want to validate passwords, they should roll it by hand or pull in another gem to fully take that responsibility. Why do half measures either way?

fthobe · 2025-03-17T21:00:01Z

It seems a bit non-sensical to have to pull in additional dependencies if I'm using Devise validatable already.

Fully agree.

gregmolnar · 2025-03-17T22:06:21Z

Just my two cents, but if Devise validatable is already doing length validation, it seems to make sense to also allow the option to configure complexity, as it is part of what would determine a valid password in the context of a Devise based authentication system.

Length matters way more than the "complexity" these options would offer.

It seems a bit non-sensical to have to pull in additional dependencies if I'm using Devise validatable already.

Fair point, but I still wouldn't recommend using these validators, because they give you a false sense of security.

To me, the logical outcome from your stance is to actually fully drop validatable all together, and if people want to validate passwords, they should roll it by hand or pull in another gem to fully take that responsibility. Why do half measures either way?

I think then it would be better to accept a new dependency(two actually) and add a new validator that uses zxcvbn and another one that uses the pwnd gem so folks could choose the ones they want to use.

kykyi · 2025-03-17T23:14:35Z

It feels completely within the remit of a Devise - an authentication solution - to provide password validations, whether through the means proposed in this PR or through some other means.

gregmolnar · 2025-03-17T23:20:04Z

It feels completely within the remit of a Devise - an authentication solution - to provide password validations, wether through the means proposed in this PR or through some other means.

It already does that, although it could do even more. But, (don't take it wrong) your solution gives a false sense of security.
Let's give the maintainers some time to sort out maintenance of the gem and then introduce 2 new validators. One based on zxcvbn and one based on pwnd. Ideally both would be used in tandem, but even if one of them used besides the current length validator, that would enforce pretty good passwords.

kykyi force-pushed the feautre/provide-config-options-for-password-complexity branch 2 times, most recently from 98a037a to a6301cc Compare November 22, 2024 04:03

kykyi commented Nov 24, 2024

View reviewed changes

lib/devise.rb Outdated Show resolved Hide resolved

datpmt reviewed Dec 11, 2024

View reviewed changes

test/models/validatable_test.rb Outdated Show resolved Hide resolved

datpmt reviewed Dec 11, 2024

View reviewed changes

test/models/validatable_test.rb Outdated Show resolved Hide resolved

kykyi force-pushed the feautre/provide-config-options-for-password-complexity branch from 36e5f42 to 776a657 Compare December 15, 2024 22:37

kykyi requested a review from datpmt December 17, 2024 00:55

kykyi mentioned this pull request Dec 18, 2024

Add has_complex_password method for out of the box password complexity validation rails/rails#53984

Closed

4 tasks

kykyi closed this Dec 19, 2024

kykyi reopened this Jan 5, 2025

kykyi force-pushed the feautre/provide-config-options-for-password-complexity branch 2 times, most recently from ee6bea3 to 44dca10 Compare March 9, 2025 03:56

kykyi added 7 commits March 9, 2025 15:02

Introduce config to allow for password complexity

0a11a86

to be validated in :validatable with lower case, upper case, numbers, and configurable special character presence to be validated on.

Update password complexity to be a hash instead of individual keys

c33db57

Update docs on Devise::Models

17af34f

Update from PR review

7918fb4

Remove require_special to make the presence of special_characters imp…

36ffdfa

…ly a special character is required

Enforce special character as any non-word character using \W

929d1cd

Update tests to assert adding the required character made the passwor…

3c86a71

…d valid

kykyi force-pushed the feautre/provide-config-options-for-password-complexity branch from 44dca10 to 3c86a71 Compare March 9, 2025 04:12

Update README to include info on password strength

b9332e5

Default special characters allowed to all chars accepted by \W, but a…

b4b90d6

…lso provide a configurable list of special chars

kykyi commented Mar 9, 2025

View reviewed changes

fthobe approved these changes Mar 9, 2025

View reviewed changes

Introduce config to allow for password complexity #5727

Are you sure you want to change the base?

Introduce config to allow for password complexity #5727

Conversation

kykyi commented Nov 22, 2024 • edited Loading

kykyi commented Nov 24, 2024

kykyi commented Dec 3, 2024

datpmt commented Dec 9, 2024

kykyi commented Dec 9, 2024

datpmt commented Dec 9, 2024 • edited Loading

kykyi commented Dec 10, 2024

datpmt Dec 11, 2024

Choose a reason for hiding this comment

nvasilevski commented Dec 18, 2024 • edited Loading

kykyi commented Dec 18, 2024

timdiggins commented Dec 19, 2024

fthobe commented Jan 5, 2025 • edited Loading

kykyi commented Jan 5, 2025

fthobe commented Jan 5, 2025

fthobe commented Jan 7, 2025

fthobe commented Jan 16, 2025

datpmt commented Jan 16, 2025

fthobe commented Jan 16, 2025 • edited Loading

timdiggins commented Jan 16, 2025 • edited Loading

fthobe commented Jan 16, 2025

datpmt commented Jan 16, 2025

kykyi commented Mar 9, 2025

fthobe commented Mar 9, 2025

salzig commented Mar 9, 2025

fthobe commented Mar 9, 2025

kykyi Mar 9, 2025

Choose a reason for hiding this comment

fthobe left a comment

Choose a reason for hiding this comment

kuahyeow commented Mar 10, 2025 • edited Loading

fthobe commented Mar 10, 2025

salzig commented Mar 10, 2025

kykyi commented Mar 13, 2025

crespire commented Mar 14, 2025

fthobe commented Mar 15, 2025

gregmolnar commented Mar 15, 2025 • edited Loading

crespire commented Mar 17, 2025

fthobe commented Mar 17, 2025

gregmolnar commented Mar 17, 2025

kykyi commented Mar 17, 2025 • edited Loading

gregmolnar commented Mar 17, 2025

kykyi commented Nov 22, 2024 •

edited

Loading

datpmt commented Dec 9, 2024 •

edited

Loading

nvasilevski commented Dec 18, 2024 •

edited

Loading

fthobe commented Jan 5, 2025 •

edited

Loading

fthobe commented Jan 16, 2025 •

edited

Loading

timdiggins commented Jan 16, 2025 •

edited

Loading

kuahyeow commented Mar 10, 2025 •

edited

Loading

gregmolnar commented Mar 15, 2025 •

edited

Loading

kykyi commented Mar 17, 2025 •

edited

Loading