The trick is to use passwords of 10 characters or more.
A traditional minimum length for
random passwords is 8 characters. The current
NIST”s policies permit as low as 6, but that is only under an assumption, that the system has working rate limiting
(1). The key is high entropy and password length has to be expressed in terms of that value. There is no one-fits-all solution and even the good, old “8 characters” is now missing foundations other than being well tested.
Using capital letters, numbers, and special characters makes it virtually unbreakable.
That topic has been discussed earlier. While using larger alphabet increases possible passwords space, it is not the only factor to consider. If you are using a password manager and generate long passwords randomly, use as huge alphabet as you want. At least as long the target sytem supports all the characters. Be careful with a backslash, a percent sign, a quotation mark, an apostrophe, an ampersand and some other character that may be rejected or handled inproperly by badly designed systems.
No, those characters do not magically make a password “virtually unbreakable”. They make easy to overcome in the simplest attack, while a properly chosen lowercase-only password will protect you much longer… and will be easier to remember, if needed. After all you need to memorize at least a few passwords, the one to the password manager being one of them. The key to high cost and low probability of breaking is, as stated above, high entropy. Actually a 21-word passphrase chosen using diceware (only short, lowercase English words!) or a 40-character password of A-Za-z0-9 +others is… unbreakable using brute force within the
current physics regime(2). For everyday security you do not need that much.
If you are not using a password manager, using too large alphabet will make password hard to remember, but will add very little entropy bits to it. High cost for little gain.
And change it at least monthly.
Except that it is very hard to follow the policy of changing passwords monthly, can you provide any reason to use that value? In particular in the context of already provided arguments of either dropping the policy altogether (in most cases it harmful) or seriously considering pros and cons of using it. Also, if you are afraid of a password being leaked so much, that you want to change it each month, what are you doing with your keypairs or certificates? A time to distribute a public key is more than a month. Getting certificates each month is prohibitely expensive for nearly everyone and in some cases CA policies do not allow that at all. But, obviously, you must follow the same principles in their case.
And don't use any real words in your password.
Actually you may use standard English words in your password and use only lower case letters. And you will have a password stronger than “MN49%b5$*8#r$”.
____
(1) Don’t think it is as easy to implement, as you think. Blocking bruteforcing of a single account seems pretty straighforward, but still with some caveats (a simple 3-attempts rule may DoS your system). Doing the same for reverse-bruteforce attacks — not so much, especially against a stealthy adversary with resources.
(2) Iterating all those passwords is alone would require the amount energy that is unimaginably great, even if the hypothetical iterating machine would be the most efficent possible. And current computers are not even close. Even half of that length would require dedicating USA’s yearly energy output to just iterating the possible passwords. Of course new discoveries may invalidate the principle or advances in comutation may permit overcoming it, but do not expect miracles soon. And even if that principle fails, still chances of a random bit in RAM getting flipped by cosmic radiation and allowing an invalid password are higher than finding the password.