For best results, use a password generator that can give you a long, random string"
This is the myth that's persisted for forty years despite all changes to the threats space. The problem is that practically nobody can actually use a password of this type, so it's self-defeating, and it also offers practically no defence in the case of offline attack.
So here are some truths:
 once the perp has a raw password hash, there's absolutely no defence against a rainbow table that can accommodate the length of your password, regardless of how 'complex' [sic] it is. The only difference is whether it takes a few seconds or a few minutes to find it. Adequate salting helps the defence, but the real trick is to prevent the perp laying hands on your password database in the first place, and that's not a user responsibility. It's down to network security.
 in the absence of getting hold of the database, the perp either has to infiltrate your front line (capturing passwords as they are entered) or has to keep trying based on published frequency lists until they succeed. In the first case, it doesn't matter a toss what your password is -- you're handing it to them, and the only defence is endpoint security, which once again is not a user responsibility. In the second case, there are several ways to make retrying randomly impractical, which is (yet again) not a user responsibility.
The only fundamental user responsibility is to choose a non-obvious password of a minimum prescribed length, and that's down to proper training that successfully instils the necessary understanding of why passwords have to be defined like this. The prevalence of impractical mandatory password rules without any supporting explanation (and indeed "letmein" as a password) shows this is not happening. The most fundamental rule that is not being imparted is:
a password is not to give you access -- it's to deny access to others, so don't make it obvious.
But I've never seen that stated plainly in any password policy I've seen over two decades of consulting.