Seems incorrect; 10 "Numbers, Upper and Lowercase Letters" is 64^10 = 2^60, and with properly applied key stretching (a difficulty factor of 2^30, say), that's 2^90. To do 2^90 hash operations in 3 weeks would require to do almost 700 quintillion hash operations per second. Bitcoin hashrate is 7.983.858 terahashes per second, almost a hundred times lower. Hivesystems is proposing "a hacker" with a hundred times as much power as the entire Bitcoin network, assuming your PBKDF's difficulty factor is set to 2^30.
Oh, reading the page at https://www.hivesystems.io/blog/are-your-passwords-in-the-green, they're assuming your password hashing algorithm is just plain MD5 without any hash iteration, claiming is "2018 cybersecurity practices". @Tutanota, please tell me are not hashing your users' passwords with plain MD5 without any hash iteration? Because Unix has iterated its password hashing function since 7th edition Unix, 25 iterations of modified DES: https://en.wikipedia.org/wiki/Crypt_(C)#Traditional_DES-based_scheme. That was in 1979. The password encryption approach Hive is suggesting has been known to be bad practice since 1979. When PHK implemented md5crypt for BSD in the 90s, it used 1000 iterations of MD5. A single iteration is not 2018 practice.
(Some people surely did commit this error in building their systems.)
Aren't actually proposing "a hacker" with a hundred times as much power as the entire Bitcoin network; are proposing to rent eight A100 GPUs from Amazon AWS which they say would get 523 billion hashes per second, the which is 16 million times less compute than the Bitcoin network. At this speed 2^90 hashes would take 75 million years, not the 3 weeks they state, the which is correct for 2^60.
If Hive is willing to assume that your security design is such shit that you're using MD5 without iteration for password hashes, why not just assume you're storing the password in plain text? That's pretty much the same level of incompetence, and it would make all the cells in the table read "Instantly". They actually do have this table further down in the post.
Hive also produced some tables for PBKDFs that have tunable difficulty parameters, such as bcrypt() and PBKDF2, but didn't specify which parameter settings are being used for these tables, or talk about the tradeoff space; also, incorrectly describe bcrypt() as not being "a key derivation function like PBKDF2", when that's exactly what it is.
