Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update Validate.hs #31

Merged
merged 1 commit into from Jan 3, 2021
Merged

Conversation

agentultra
Copy link
Contributor

@agentultra agentultra commented Dec 8, 2020

Added a link to the NIST 800-63b publication on authentication credentials and life cycle management to the module haddocks and change the defaultPasswordPolicy to follow the NIST recommendations.

The default character set will need to be updated as well to include the full unicode character range and ensure that multi-code point glyphs are handled as per the guidelines.

Fixes: #30

Added a link to the NIST 800-63b publication on authentication credentials and life cycle management to the module haddocks and change the `defaultPasswordPolicy` to follow the NIST recommendations.

The default character set will need to be updated as well to include the full unicode character range and ensure that multi-code point glyphs are handled as per the guidelines.
@Vlix
Copy link
Collaborator

Vlix commented Dec 8, 2020

Hey @agentultra , thanks for contributing! I've read a bit of the addendum, and it seems intuitive in a sense.

Seeing as there are still people/businesses that require passwords to adhere to some of these "at least 1 ... " conditions, I think it's ok to keep the general shape of this module, though it might indeed be a good idea to change the default so it's a sensible default.
That and including an explanation why requiring these things might a bad idea when "validating" passwords.

After reading the addendum of the paper, I feel it might be a good idea to also change the default length fields.
8 minimum chars and 64 maximum chars seems a bit on the low side if you don't require inclusion of more than one character category. Especially if "the longer the better".


A few questions, though:

  • can you provide what "the guidelines" are on the handling of multi-code point glyphs?
  • would you agree that it'd be a good idea to tell users of the module that encouraging long passwords is preferred over requiring multiple character categories?
  • do you think it'd be a good idea to also include checking using the zxcvbn library that someone on reddit suggested?

@agentultra
Copy link
Contributor Author

Hello @Vlix

I agree that there aren't any dramatic changes required of this module. While I am opinionated on the matter they are guidelines and users should definitely be able to decide whether to follow the posted speed limits. What this change accomplishes is to provide sensible defaults based on industry best practices.

To answer your questions:

  • Section 5.1.1.2 gives the prescriptive requirements. I wasn't sure about Unicode so I didn't add it in this change and looking at the guideline, Unicode isn't mandatory. If it is used glyphs represented by 2 code-points should be treated as a single character for purposes of length checking. There's some additional stuff about normalization for hashing.
  • Yes, that's what I hoped the updates to the haddocks would do but paraphrasing the relevant parts in proper documentation would also be beneficial
  • I'm not familiar with that particular library :)

@agentultra agentultra marked this pull request as ready for review December 9, 2020 14:29
@Vlix Vlix changed the base branch from master to documentation-update January 3, 2021 18:29
@Vlix Vlix merged commit 0f4a00d into cdepillabout:documentation-update Jan 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Update documentation on password policy validation
2 participants