Enforce strong passwords

[asbiin]

Currently, the only limitation for passwords is: they have to be 6 characters long.

We should enforce passwords strengh, by forcing the user to:

• mix case characters
• add numbers
• add special characters (symbols)

We could add this package and make sure we enforce strong passwords : https://github.com/schuppo/PasswordStrengthPackage

[djaiss]

Ideally, you would explain why we need this in the body of your issue, so we can discuss the feature itself.

[allo-]

Have a look at https://github.com/dropbox/zxcvbn. The library avoids some of the mistakes of common "strength meters", which often classify "Password&1" as strong (Lowercase, uppercase, more than 8 chars, special char, number). The static hash list from haveibeenpwned is another good idea.

[artis3n]

Instead of password strength by requirements for symbols, numbers, no repeated chars, etc. which are generally the Bad Way to do password checks these days, consider implementing a check that the entered password has not been exposed in a breach - https://haveibeenpwned.com/API/v3#PwnedPasswords . Current best practice is simply 8-character minimum with an exposure check.

To prevent abuse, an API key costs $3.50/month for calls to Have I Been Pwned. That's not the only service but probably the best. This could be built into by the .com service and an ENV VAR for people to enable on their self-hosted solutions should they want breached password protection.

Auth0 / NIST on password best practices: https://auth0.com/blog/dont-pass-on-the-new-nist-password-guidelines/

[acuteaangle]

The password check API is actually free.

The Pwned Passwords API is freely accessible without the need for a subscription and API key.

The subscription API is for finding all breaches a given email is found in, not for checking passwords.

The HIBP API is pretty simple, and only sends the first 5 characters of the SHA-1 hash to HIBP. The service then sends back the rest of the hash for all matches (along with how many times they've been breached, in case you want to display that) and the search is completed locally.

There's almost certainly a nice library to abstract away the API calls and comparisons.

---

As far as the main topic of the issue, I do not believe requiring special characters/capitals/numbers is at all a good idea.
Many password managers and systems like Diceware (generated word sequences) create perfectly secure passwords without that, and people making up passwords on their own are incredibly likely to capitalize the first letter and add '1!' to the end, or similar.
I agree with the previous commenters that a minimum length, HIBP check, and zxcvbn meter would be ideal.
(And a maxinum length, if necessary for network reasons, should be at least 255 bytes, to allow for secure passphrases and non-Latin scripts assuming UTF-8 is supported.)

I highly recommend reading the Memorized Secrets section of the current NIST Guidelines.

I use a password manager that generates Diceware passphrases by default (so that they're all easy to type in from my phone or potentially memorize if I need to login on a system without my password manager), and it's incredibly annoying when a service rejects my perfectly good passphrase for arbitrary requirements.