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?

[sigmavirus24]

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.

Because people don't only interact with Warehouse via a browser. Even so, JavaScript should never be the only form of verification. Even someone using a browser can modify the request before it is actually sent, which will bypass any JavaScript validation. Providing JS validation is merely a UX enhancement. Providing server-side validation is providing the actual service.

[controversial]

It’s not merely a UX enhancement, it enforces security for the vast
majority of users. The question comes down to how strongly we want to
enforce password security. I don’t think it’s completely black and white. I
see your point, though.

On Sat, Jul 2, 2016 at 9:07 PM Ian Cordasco notifications@github.com
wrote:

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.

Because people don't only interact with Warehouse via a browser. Even so,
JavaScript should never be the only form of verification. Even someone
using a browser can modify the request before it is actually sent, which
will bypass any JavaScript validation. Providing JS validation is merely a
UX enhancement. Providing server-side validation is providing the actual
service.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#6 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AJ5Yr4k8m-KzpSDO8eQ9SNhvFjydGFtpks5qRws6gaJpZM4AmCnn
.

[demianbrecht]

The question comes down to how strongly we want to
enforce password security.

Very strongly :)

Without sufficient password strength on the server, as Ian mentioned, we leave users open to passwords that aren't sufficiently strong, which reduces user security. Because of the reduction of user security, it increases the risk to packages managed by a given user. Package integrity and security are of paramount importance, so everything that can be done to increase user-level security is a Good Thing.

[controversial]

Right. Makes sense. I keep forgetting that this is a service under which
thousands of people can rely on the security of a single account (Imagine
if requests was updated to install spyware on users’ machines). So this
option is out.

On Sat, Jul 2, 2016 at 9:20 PM Demian Brecht notifications@github.com
wrote:

The question comes down to how strongly we want to
enforce password security.

Very strongly :)

Without sufficient password strength on the server, as Ian mentioned, we
leave users open to passwords that aren't sufficiently strong, which
reduces user security. Because of the reduction of user security, it
increases the risk to packages managed by a given user. Package integrity
and security are of paramount importance, so everything that can be done to
increase user-level security is a Good Thing.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#6 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AJ5Yr1zhF52ANmunYmORoZLFA3NN8lrPks5qRw5BgaJpZM4AmCnn
.

[dstufft]

I'm going to drop this out of the shut down milestone since this is implemented for the server side validation (which is the actual important one) and the only thing left is to implement it client side (which is just a UX enhancement).

[brainwane]

Given that the UX enhancement is what the end user sees and understands, I'm adding this back into the "shut down legacy PyPI" milestone. :)