Introduce config to allow for password complexity

[kykyi]

In relation to #5591

This PR introduces application config to allow for password complexity to 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_length = 8..128 # (existing)
      config.password_requires_lowercase = true
      config.password_requires_uppercase = true
      config.password_requires_number = true
      config.password_requires_special_character = true
      config.password_special_characters = ":)"
end

Note

• I haven't run any linting, I couldn't find instructions on what config was used for that 😄
• I haven't updated any docs, please advise where I need to update if at all 🙏

[kykyi]

Hey @nashby if I could please request a review 😄

[kykyi]

I wonder if there could be some more general config like:

  @@require_complex_password = false

Which if true would require all of these individual pieces?
So the validations could become:

validates_format_of :password, with: /\p{Upper}/, if: -> { password_requires_uppercase || require_complex_password }, message: :must_contain_uppercase

[kykyi]

Polite bump @nashby @carlosantoniodasilva 😇

[datpmt]

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]

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]

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]

@datpmt updated to use your dict style ✅

[datpmt]

Suggested change

	require "test_helper"
	require 'test_helper'

Prefer single-quoted strings when you don't need string interpolation or special symbols.
References: rubocop

[datpmt]

Useless assignment to variable - original_value.

[datpmt]

Suggested change

	test 'should require email to be set' do
	test 'should require email to be set' do

remove redundant space

[nvasilevski]

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]

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]

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]

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:

1. having password managers;
2. having preferably time generated OTP tokens;
3. 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]

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]

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]

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