Use zxcvbn-js directly instead of devise_zxcvbn

[monfresh]

Why:

• The implementation of server-side password strength validation based
  on zxcvbn should be compatible with any authentication system.
• Using the devise_zxcvbn gem means the validation is tightly coupled
  to Devise and to the User model, which is not ideal.
• The devise_zxcvbn gem's inefficient code added over 2.5 minutes to
  our test suite.

How:

• Add the validation code directly to our FormPasswordValidator
• Optimize the code for performance
• Use Figaro to configure the minimum password score, and to allow the
  validation to be disabled by default in the test environment. It can
  be overriden in specs that test the strength validation.

[pkarman]

I will confess I resisted this idea at first but it is consistent with how we validate lots of data model attributes. Just some small nit comments.

[pkarman]

should probably not refer to code we are not using.

[monfresh]

Good catch. Copy and paste sloppiness on my part.

[pkarman]

how about strong_password instead of not_weak_password ?

[pkarman]

although I see naming consistency with the word weak

[monfresh]

I thought about that. I went with what the gem was using, and I was trying to figure out why they made that choice. I'm fine with changing to strong_password.

[monfresh]

Thanks for the feedback. I addressed your comments in my second commit.

The main reason we don't want to include the validation in the User model is because it involves expensive calculations that don't make sense to run when the password is not being validated. This is what was slowing down our test suite, and would have negatively affected the performance of our app.

Because of the way we are breaking up the default Devise sign up form into two parts: email first, then password, there is no way to make the password_required? method return true only when the password is being created or updated, without resorting to hacks like setting an attr_accessor in the User model and setting it to true in the controller(s) where we want the validation to take effect. This is what I undid in #105.

The one downside of not having validations in the model is that someone with access to the console could potentially create a User with a weak password. I don't foresee anyone of us ever doing that, and if an intruder had access to our console, then that would be the least of our worries. If we really wanted to prevent that, one way I can think of is to use a Data Type class and serialize the password column to use that class. I haven't done anything like that personally, but I saw an interesting talk about it. Here are the slides.

[pkarman]

lgtm