Validate Complexity of Passwords

[dstufft]

Ensure that user passwords always match some level of password complexity/strength.

[nlhkabu]

I'd like to indicate password strength client side too... we'll need to look into a plugin for this.

[dstufft]

I think Dropbox has a js library for it.

Sent from my iPhone

On Nov 21, 2015, at 4:25 PM, Nicole Harris notifications@github.com wrote:

I'd like to indicate password strength client side too... we'll need to look into a plugin for this.

—
Reply to this email directly or view it on GitHub.

[alex]

https://github.com/dropbox/zxcvbn

[nlhkabu]

Nice!

[demianbrecht]

@dstufft @nlhkabu: What's the status of registration flows? I'm interested in taking a run at this, but noticed that there's been similar work done in #334 (which was closed).

[nlhkabu]

Sounds great from my end @demianbrecht !

I have not yet started on the design, so the best way to build the templates is to make them functional only (i.e. don't worry at all about how it looks at all). Once your PR is merged, I will come through and apply the appropriate styling.

[dstufft]

The status is they still need to be written. That PR is old and it's against a version of Warehouse before I rewrote it in Pyramid so it's not directly usable.

[demianbrecht]

Thanks @nlhkabu and @dstufft. I was a little swamped last week but I'm hoping to get some time to devote to this during this week.

[demianbrecht]

While working on the registration flow, I took a quick look at zxcvbn. I was hoping that the Python port would be consistent with the initial JS implementation. Sadly, that doesn't seem to be the case (dropbox/python-zxcvbn#14) and would lead to inconsistencies between server and client side, which wouldn't be so hot.

A few potential paths I can think of:

1. Fork the project (it seems to have been abandoned) and update it to match. I'm not terribly keen on doing this due to time constraints, but if someone else is willing, then great
2. Only have server-side complexity validation
3. (In addition to 2.) Adding a server-side endpoint for FE validation calls
4. Roll our own consistent implementation between server and front end

I think I'd favor either 2 or 3 depending on which way the wind blew.

[demianbrecht]

@nlhkabu until there's a matching fe/be implementation, [here's what's recently been added] for password strength. Should be trivial to implement something matching in JS as a stop gap until a better replacement is found.

[controversial]

@demianbrecht @dstufft @nlhkabu Why are we concerned about server-side password strength evaluation? We could use only the JavaScript library, and validate password strength before allowing the user to submit the form, and we could do nothing server-side.

Of course, the viability of this option depends on whether we're concerned about the potential vulnerability (which I don't think we are): the determined user could theoretically use the JavaScript console or even just curl to submit false results about password strength, such as giving password a maximum strength rating, but that's probably not a huge concern. Because it would only affect the user in question, nobody else, the user is only hurting himself / herself.

What's the opinion on this? Why do we need to have password strengths stored if they could be easily computed and re-computed with JavaScript?