Implement password validation criteria

[clash99]

Decide minimum password requirements and implement in both client and server side validation.

[dpalomino]

Can this be a dup of #273?

[oliverroick]

Yes, it is. We should close the older one.

[clash99]

@dpalomino: I need business requirements on this one based on our past tech meeting discussions.

[dpalomino]

Hi @clash99.

I was thinking in requiring:

• Password must have at least 8 characters
• Password cannot contain the username
• Password cannot contain the email username
• Password cannot include words contained int the full name (like first name, or family name) with more than two characters (so "Michael J Fox" would mean that password could not contain "Michael" or "Fox").
• Passwords must have at least three of the following four character types: numbers, lowercase letters, uppercase letters, symbols

Requiring a longer password would increase the security as @ian-ross pointed out, but my concern is that it might make more difficult to remember for the average user.

What do you think?

[clash99]

@dpalomino: What about integrating some sort of password strength indicator? Let me do a little research today and come back with some recommendations for you to review.

[amplifi]

@dpalomino I think at an absolute bare minimum we should require 10-character passwords with all four of those criteria (lowercase, uppercase, numbers, symbols). Better would be a 12-char minimum, with 20+ being the recommended password length, but I realize that may not be feasible for some of our partners.

This article is from 2012 so GPU speeds have increased since and costs for computing are cheaper, but an 8-character password was woefully insufficient:

http://arstechnica.com/security/2012/12/25-gpu-cluster-cracks-every-standard-windows-password-in-6-hours/

The 2012 recommendation was that passwords should never be less than 9 characters with a mix of upper/lower/num/symbols.

http://passfault.com also has a tool allowing you to estimate the amount of time it would take to crack a given password.

[seav]

The article says that the best way to mitigate having shorter passwords is to use a hash algorithm specific to hashing passwords, such as bcrypt instead of regular ones like MD5 or SHA256. Django by default uses PBKDF2 which is tunable and already comes with Django. But it seems that based on a 2015 password hashing algorithm competition, the currently recommended algorithm (which Django also recommends) is Argon2 because it is slow and tunable, and it is designed to resist hardware-based (GPU or custom ASIC) password cracking implementations. Fortunately, Django can support Argon2; we just need to install a 3rd-party library.

So I would recommend having 10 characters as a minimum with the 4 types of characters (lowercase, uppercase, numbers, symbols), and then switching to Argon2.

[amplifi]

That works for me 👍 I'll create a new issue for transitioning to Argon2, as it's outside the scope of this issue.

[dpalomino]

Thanks @amplifi @seav for the feedback!

I am concerned about our users are in general not familiar with technology at all, so requiring long and complex passwords could be a barrier. In particular, I think symbols could be an issue (specially when configuring ODK/GeoODK in smartphones).

What do you think about requiring a minimum length of 10 chars and 3 of the 4 types (lowercase, uppercase, numbers, symbols)? Would that be something reasonable?

[seav]

@dpalomino, I'm OK with requiring only 3 of the 4 types.

[ian-ross]

Everyone interested in this issue should read this paper ("Do Strong Web Passwords Accomplish Anything?"): https://www.usenix.org/legacy/event/hotsec07/tech/full_papers/florencio/florencio.pdf There are better solutions than complicated rules about character classes. In particular, exponentially increasing retry delays make brute-force attacks against individual accounts essentially impossible.

[amplifi]

@ian-ross I believe there's a delay implemented after 5 failed attempts already, but switching to an exponential backoff would definitely be an improvement. I still think we need a combination of password complexity, strong hashing, and UI-based protections, because the latter won't help in the event of a server- or database-level breach.

[ian-ross]

100% agree with strong hashing!

[dpalomino]

So, just to summarize and check that we're on the same page, regarding password validation criteria we can agree on:

• Password must have at least 10 characters
• Password cannot contain the username
• Password cannot contain the email username
• Password cannot include words contained int the full name (like first name, or family name) with more than two characters (so "Michael J Fox" would mean that password could not contain "Michael" or "Fox").
• Passwords must have at least three of the following four character types: numbers, lowercase letters, uppercase letters, symbols

And in addition:

• We switch to Argon2 (issue #876)
• At least we maintain the delay after 5 failed attempts

Please, let me know if I'm missing something...

[wonderchook]

Need to figure out how to deal with passwords being forgotten for people that don't have email addresses.

[dpalomino]

After a conversation with @clash99 we decided to skip the Full name requirement (i.e. preventing passwords with words contained in the full name). There could be conflicts due to Full name not being a mandatory field, and also because users can update their Full name after creating the account.

It's been also agreed to require a minimum length of 3 characters for the username (we currently have no minimum length) also to avoid conflicts with the password validation criteria.

[clash99]

@dpalomino - Please review the help-text and error messages for the password field below. Its complicated so let me know if you have ideas on how to simplify any of the messaging. I'm going to wait for approval before entering them in transifex for translation.

Other ideas for ui improvements (future sprint):

• Implement a password strength indicator that will provide user instant feedback (I could change validation to keyup trigger now if you think that will help too)
• Implement a "show password" option where users can toggle the view of the password input

[dpalomino]

Thanks a lot @clash99. They look good to me. Yes, I think the password strength indicator would be quite useful for the future.