-
Notifications
You must be signed in to change notification settings - Fork 67
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
Intention of options #4
Comments
Right now, Would you prefer re-generating a password until it contains a character from each individual pool? It seems to me like that would be the only solution here. Thoughts? |
I'm currently struggling with that decision right now. Do we use brute force to ensure these requirements are met, by re-generating a new password? Is there an acceptable amount of force that we can apply? One other option that I'm exploring at the moment, is to provide an option for pattern matches that must be met. However, even this strategy requires us to re-generate the password. For my particular use case, I have the following requirements.. which are quite intense :) We're using OWASP guidelines as our password requirements
There's gotta be a gentle way to handle this use case. I really like your approach with the |
I'm currently looking at the password-generator project, for inspiration. I initially tried going with that project, but there is a limitation of the pattern match capabilities that won't meet my needs. Maybe you can find something useful here.. |
I see that you have to follow guidelines - which, mathematically speaking, I think would actually decrease the entropy in any single password. I think those would only be intended for humans, but that is irrelevant. I don't think there is a better solution that regenerating until we get a good one, because otherwise we might have to deal with complicated randomness weighting, which will probably end up reducing the entropy of the password in ways we might not intend. I wouldn't say brute force is the right term, as numerically speaking the odds if it happening multiple times in a row are very slim, but it does have a pretty bad worst case. I wouldn't have a problem with putting this in the library, would it fit your requirements? |
If you're comfortable doing so, I do believe it would fit my needs. I'm very curious to see your implementation as well. I've gotten the 5th requirement, from above, implemented: Must NOT contain sequences of three or more repeated characters. I'm not sure if this is the best way to go about it. Here's a link to my branch, with these changes. I'm just providing this as an example. I'd like to see what your approach to this would be. Had some spacing issues with this commit. https://github.com/mleanos/generate-password/blob/options-require-inclusion/src/generate.js Thanks for your help. I appreciate it. |
not sure if this would help...here's the ESAPI java api to generate a strong password.. |
Nearly one year later, this PR should finally close this issue: #8 :) |
I'm curious as to the intention of the
options
parameter. At first glance, my interpretation was that if I passed any of the options in astrue
, then thegenerate()
method would force them as a requirement. However, the implementation doesn't appear to follow that logic.What that said.. What do you think of forcing any options that are set to
true
to be a requirement of the generated password? Or perhaps, introducing other options that would serve this need?The text was updated successfully, but these errors were encountered: