I believe that since the problem is solved by adding a couple more characters to the password it is not really an issue. We are not talking about getting the length up to 20-25 characters but just to 9-10. Which is still quite easy to remember.

Sure, it takes away all the combinations that use characters from some instead of all the character groups you mentioned but it is easily negated by the password length.

Plus the number one rule to make your password "immune" to brute force is making it longer than 8 characters (by today's standards, correct me if I'm wrong). Most of the sites that test passowrd strength suggest so.

Yes, I think the theory is correct, but the practice is different.

You presume that the passwords are random, so the avg number of guesses is close to the median. In reality people will use same common passwords and the guesses will be sorted by popularity. By enforcing these rules I suppose it is a forced way to enlarge the set of common passwords.

I personally hate these rules, because I cannot use the most secure passwords and easy to remember (which are a long set of common words) :(.

Ideally, I'd rate limit the auth api and check against a list of commonly used passwords (and against a db of previously compromised usernames/passwords), then ditch the rules and stop worrying about brute force.

I think enforcing numbers & special characters reduce the odds of a simple dictionary attack.

BTW, usually special characters are limited; encoding & such.

Requiring one of each special character doesn't narrow the attack space. You have to remember that the attacker doesn't know the password unless it's guessed correctly. They don't know the order and which characters satisfy which requirements. Therefore to the attacker, every character could be any of the 96. Character requirements enforce that a user takes advantage of the full character space and that the attacker has to try 96^6.

People a lot smarter than me already have concluded that password length is all that matters, any other rules will only reduce the effect because people will use more predictable passwords. This combined with special slow hashing algorithms designed for password storage (e.g. bcrypt) is how to handle passwords.
This is just for passive password security, for when the credentials storage is leaked.
For the active service you obviously want to add MFA, temporary account locks, additional verification like recaptcha.

There also this nice XKCD:

threatpost.com/proposed-nist-passw...

NIST recently loosened recommended password length and complexity. Basically, they found that strict password policies just lead users to do things they should not be doing like reusing passwords, writing them down on post its because they are hard to remember, transposing letters with numbers so they can use dictionary words, etc. This is a much bigger problem because it facilitates things like social engineering.

Instead of putting the burden on your users, verify their passwords against blacklists, recommend they use a password manager (with random generated passwords), implement 2FA (and soon webautn), and rate limit your APIs to prevent brute force attempts. That's a good start. If you implement length limitations at all, go for something like 16 characters. Anything less is technically not really that helpful against brute forcing and chances are that users just add something like 12345 to the passwords they use elsewhere that is already on a compromised password list (i.e. trivially brute forced).

And for the love of god, use bcrypt with salted hashes (especially if you don't know what those are). Nothing else is even remotely acceptable. Don't even try to reinvent/improve that stuff. There are perfectly good OSS implementations for just about any popular language out there that have been properly audited, battle tested, etc. If you are not using those, you are doing it wrong.

If you set up your rules to say that you need to match at least n criteria, such as "> 1 special character", "> 0 uppercase", "total length > 20 characters", etc. then you can keep that magic number big. Explaining these rules to a user in a clear manner is more difficult though.

I think Anton Frattaroli and Michiel Hendriks have it covered well. But I'll add my two cents anyways. I don't use a PW manager because I don't trust them ... eggs in one basket and maybe the basket, etc.

My technique is modelled after the security ring system. I have several levels of password from easy / non secure to hard (hopefully very secure). The one or two easy rings never change and they are used for things like newsletter / website subscriptions and blog posts. From there I use a system. I change the system every 3-6 mos. The most secure ring is email and the next secure is banking and credit cards.

For example, a system could be based on flowers:

step 1: choose a number of flowers or flower phrases from easy to hard, use camel case for phrases:

Rose
Daisy
Orchid
Marigolds
Dandelions
Chrysanthemums
StopToSmellTheRoses

Step2 Leet the vowels and special character some letters

R0$e
D41$y
0r(h1d
M4r1g0ld$
D4nd3l10n$
Chry$4nth3mum$
$t0pT0$m3llTh3R0$3$

Step3 - append or prepend the name or abbreviation of each website:

So, for Amazon which would be a banking / credit card site:

Chry$4nth3mum$-Amazon becomes Chry$4nth3mum$-4m4z0n

Then every so often change the formula ... cars, animals, mineral names, state capitals, cities in Europe, etc.