Intention of options

[brendanashworth]

Intention of options

[brendanashworth]

Right now, options just increases the size of the "character pool", i.e. enabling symbols allows the password to contain symbols, rather than guarantee that symbols be in the password.

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?

[mleanos]

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

1. Must contain at least one number
2. Must contain at least one uppercase letter
3. Must contain at least one lowercase letter
4. Must contain at least one special character
5. Must NOT contain sequences of three or more repeated characters

There's gotta be a gentle way to handle this use case. I really like your approach with the pool, and would prefer to find a solution that can be incorporated into this project. As it seems that even though my use case is strict, I'm probably not the only one that has this requirement.

[mleanos]

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..
https://github.com/bermi/password-generator/blob/master/lib/password-generator.js

[brendanashworth]

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?

[mleanos]

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.

[jloveland]

not sure if this would help...here's the ESAPI java api to generate a strong password..
https://github.com/ESAPI/esapi-java-legacy/blob/20438dbae5ecf8a51f454f38d1e0525fe4b61eb6/src/main/java/org/owasp/esapi/reference/FileBasedAuthenticator.java#L281
I know it's java, but the approach may be useful if you are looking for some ideas?

[brendanashworth]

Nearly one year later, this PR should finally close this issue: #8 :)

[brendanashworth]

@mleanos this has finally been added as of v1.2.0. You can use the strict option to achieve what you're trying to do. Enjoy, and thank you for opening the issue.