But I don't believe this is really a problem. As computers get faster, hashing can get slower. There is no upper limit on hash complexity.
Edit: This is your guide, isn't it? It would be ethical for you to disclose that, given that it has an advert for your business at the bottom.
It was not many years ago when strong 8 character passwords were completely suitable. So respectfully I think your statements are false.
One of the reasons the guide recommends Keepass is that it eliminates the need to type in passwords completely. Even in the rare case of poorly designed apps that block pasting, the auto-type capability works around that.
I searched around and found someone posted some hashcat-ocl benchmarks done with a Titan X about a year ago, and it could do 14440 bcrypt hashes per second. So let's calculate how many "Titan X * days" are required to brute-force such a completely random password using that character set:
>>> (26 + 26 + 10) ** 8 / 14440 / 3600 / 24
175005
If you assume the best GPU today is twice as fast, and that someone has 8 of them in a rig, that's still 10 thousand days to search all possibilities, which means 5 thousand days on average until the hash collision is found.For a typical user account, 5 thousand days of crunching by 8 of the most powerful GPUs on the market, is pretty good.
I personally go for 9 or 10 character passwords that include some symbols too, but are a bit less random ;)
Anyway, the biggest factor is to use a unique password for every account, because you can't guarantee that none of the websites you use didn't totally fuck up and accidentally put the original password somewhere, nor can you guarantee that they won't be hacked to the extent that the passwords are intercepted during sign-in.
If you were given a list a human generated passwords and computer generated passwords, you could spot the difference immediately. Passwords are not random, and crackers take this into account. Most passwords are letters with a stray symbol here and there. More advanced password crackers take a dictionary of base words and use Markov chains of passwords to try.
This greatly reduces the search space and the eon-long searches start looking more in reach.
For the people who recommend password managers, I do wonder why the password manager site is deemed to be more trustworthy than all the presumably untrustworthy (i.e. with respect to secure practices) sites, the passwords to which are stored in it?
Most password managers worth considering do not store the users' passwords unencrypted (or ever touch them unencrypted). Instead, they use a master password known only to the user, followed by a computationally expensive key derivation (PBKDF2 or similar) to create an encryption key, and encrypt the passwords with that. They then use a different derivation path to handle authenticating the user to their servers.
It's a very reasonable architecture unless you're on the extreme end of paranoia. Notably, I have about four passwords I don't store in my password manager. But I'm very happy trusting it with my bank and financial stuff.
The reality is that getting people to use a good password manager with randomly-generated passwords, regularly, on all of their accounts and devices -- with 2FA for the important stuff -- is far more important than the slight extra security risks from using the online components of the good services.