Split the logic into an independent package

[elboletaire]

I'd like to create a react component with this plugin, but without copy-pasting the logic between both components.

For that reason I'd like to split the main logic of the password-strength-meter and make that logic a dependency (in both bower and npm) of this current package.

I'm not really sure how to achieve this, so if anyone reads it and has any idea, I'm glad to read them and listen to your requests.

What I've been thinking so far:

• Get off all the calculation logic, and try to add new features to it, like being able to configure how to score system works (min characters, required characters, etc)
• Find out how the hell a jQuery plugin can use that npm package as its main logic. I'm not really sure if this can be achieved easily packaging the npm core in a specific way or, otherwise, we'll need to package that core while packing the jquery plugin
• Instead of reusing this package from version 3.0.0, which would be a PITA for many people, I'll probably create an npm namespace specific for the project. BTW version 2.0.0 will still be used as a big warning for users to move to the new one.

[elboletaire]

This should be open :\

[jhoover4]

I can help with this if you're still taking contributions

[elboletaire]

Thanks @jhoover4 but I was thinking in rewriting it from scratch tbh. I'm gonna explain what I've been thinking, so I have my thoughts written down somewhere and also others can help (not only coding, but also expressing their opinions in this issue).

When I first coded password-strength-meter I did use code from other sources which can't be currently configured (scores are hardcoded). Also, it was coded before I knew that is much more important length than symbols, numbers and other stuff in passwords. There's plenty of articles where you can find information about this, but it's easy to understand: the more characters you add, the more time will take to the attacking machine to use brute force against your password.

https://crambler.com/password-security-why-secure-passwords-need-length-over-complexity/
https://www.quora.com/Is-password-length-more-important-than-the-difference-in-characters
https://resources.infosecinstitute.com/password-security-complexity-vs-length/

For all this, I do think this library should punctuate passwords based, mainly, on their length. Obviously I'm planning on add all the other current punctuation logic, but in a way it can be configured and setting everything to disabled, except for the length which should be set to something like 23 by default.

I've been thinking on how to do the punctuation logic and I think it's as easy as split the different checks in methods for each check and add configurable mininum punctuation for them. Then, the total should be a percentage of the sum of all punctuation.

So, by default, I'd say the plugin will come configured this way:

{
  punctuation: {
    length: 23, // check it's, at least, 23 characters length.
    symbols: 0, // don't check for symbols
    numbers: 0, // don't check for numbers
    uppercase: 0, // don't specifically search for uppercase letters
    lowercase: 0, // don't specifically search for lowercase letters
    repetition: true, // allow repetition by default
  },
}

I'm using zero instead of false there because that way users will be able to customize it to, say, expect two symbols instead than one.

All this configuration will be used when calculating the strength of the password (in %). Here I'm not sure if we should add a way for users to add more weight to specific calculations (i.e. you prefer to add more weight to the symbols); I do think the length punctuation should count x2 and that no punctuation should not be configurable to ensure users don't sacrifice security; this doesn't stop users from setting length to a really low value, though (maybe the length should have a minimum hardcoded?).

Now, these are my main thoughts on the main changes. But splitting the logic into a new library means that all this logic will be in an npm package, so you can import it onto any js/node project and use the library to get a strength of a password in %.

Then, rewrite the entire jquery code to use the npm package. I'm not really sure about this part, but I think the way to go is using some kind of postprocessor like webpack. Import the npm package normally, create the jquery code using es6, but then export that es6 code + the core, all compiled into one unique package.

I'd love to find a way to not need to recompile the code for the jquery plugin, but I think it's the easiest way. Trying to make the npm core package browser compatible so it can be loaded directly via browser can be a PITA (please, if anyone knows the way, correct me if I'm wrong).

Having this, the project should be working as it works currently, but obviously with the expected changes from the logic. After that I'd like to create plugins for other libraries like react or vue, but there's some work to be done first 🙃

As soon as version 2.0.0 is published I'll start coding the base/boring stuff. I guess I'll have time during this next week, as my country just declared the state of emergency due to COVID-19*... 😞

Some other things to be noted:

• This repo will remain the same. No new repo will be created for the core package.
• The npm package will remain untouched, but with a note of deprecation in the last release, pointing to the new (jquery) package name.
• New repos will be created for the non-core libraries (jquery, vue, react..).
• New npm packages will be created for each module.

* And hopping there's still a world to live in after this shit.

[jhoover4]

Haha dude I'm right there with you here at home staying in with the Coronavirus stuff. Let's knock some of this stuff out then!

A few thoughts:

• It might be worth managing everything as one monorepo if we can. Its always easier than having multiple ones. See https://github.com/lerna/lerna
• Also it looks like there's a password validator out there now. Might want to incorporate it? https://www.npmjs.com/package/password-validator
• I also think 23 is a pretty high length, I mean I know for security its probably best, but users are also lazy :/
• I don't think rewriting the jQuery to use NPM should be too hard

Besides the above, be happy to help with whatever you decide