There is an easy answer to that: The password that does not exist as there are better mechanisms for safely and securely authenticate users. Passwords have always been an arms race between methods and password length vs. password cracking and with better and faster computers the race will be lost by the users.
That said there are still cases and environments where passwords are used for authentication and you will have to deal with these environment (independent of the reason being cost or mere practicability). In each of these cases you will have to decide how high the risk for yourself (and those you are representing) in the case of a security breach is.
So there still is the question what password is a good password and how do you create one? Many sites are trying to enforce policies on users (e. g. by defining symbol classes like “lower case characters” and “numbers” or minimal password lengths), sometimes even giving the wrong explanation. All these policies led into the wrong direction as XKCD summarized perfectly: “through 20 years of effort, we’ve successfully trained everyone to use passwords that are hard for humans to remember but easy for computers to guess”. There is only one way of measuring the quality of a password from the point of view of a machine which is called “entropy” and meaning the amount of “randomness” contained in it; in human terms this translates to “length”. Everything else is sugar coating and making things harder than necessary - on you. “last-christmas-i-gave-you-my-heart-but-the-song-sucks” is definitely a better choice than “1m50!_33T” but you will find more places where the latter is accepted with the first getting rejected for being not secure.
With the password itself being as secure as possible (there are still systems that enforce short passwords that might negate all your options to get safety from length) you still have a few more things you can do to improve your odds:
If you have never heard of “password hashers”: They are a category of tools that generate the same password repeatedly given the same input which usually consists of a (hopefully) “good” master password and something that identifies the destination (usually the site name and a user name for the site and to be able to change a password there has to be some versioning system, usually a counter). The promise here is not having to synchronize an encrypted password database (“vault”) between the computers because there is no secret database. But for comfort and adaption to password complexity policies there is metadata associated with the passwords that needs to be synchronized between all the places needing access to the passwords so you will end up with the same problem. And a new one: Can you trust the password generator and how do you deal with changing all your passwords if a flaw in the generating method has been found? This article is providing a good and not overly technical introduction to these problems.
Sooner or later, passwords escape (for a lot of reasons not necessarily being your fault at all — do you regularly check your computer if it grew some device like this?). The problem is not new; even in the stone age of computing this problem was obvious. When computers became reachable by networks like the telephone system (using dial-up modems), people had to use mechanisms to protect the access by appropriate means (at that time by having the computers calling back authorized users). It always meant adding a second factor different from the first to the authentication system. Today we have arrived at a point with a lot of cheaply available systems with different availability so anyone providing access-controlled services needing additional protection for their authentication system can provide users with various tools at low costs (to both parties). So if there is something available, use it. Well known systems are Google Authenticator (which is widely spread) or FIDO(2) security tokens. There are also smartphone based tools (but who would trust their secrets to an network-connected device not even under his own control?). Use them wherever you see them.
To permit easy (not to say cheap) recovery of lost passwords (if you had used that password safe this would not have happened to you…), many sites offer some kind of password resetting mechanisms and most of them use “personal questions and answers” as additional primitive authentication and authorization of that process. If you pass this test, something will send you instructions how to change your password (or even worse: A valid new password) by mail, sometimes without using a previously agreed mail address. Why do you believe nobody would know your date of birth (or the place)? If you have to use these mechanisms, consider them to be another secondary password. Your place of birth could be “this-is-not-a-very-secure-but-long-answer-to-a-stupid-question” and the name of your second child could be “she-who-has-never-learned-to-close-the-door-behind-herself”. Don’t worry, the computer will not judge you for your birthplace or having a lazy daughter. Even better: If you can chose your own questions and require you to enter them, too, use them as part of the password. Ask for “grzlwrgs” instead of “second and fourth character of the name of your grandmothers preferred whiskey”. Hard to remember? Use your password safe again!
“(You) don’t drink, don’t smoke, what do you do?” So what are my tools for dealing with passwords if they can’t be avoided?
Passwords for “low-value” web-based services are going into Enpass (I disliked the pricing of 1Password at the time I had to chose one and I liked the easy integration of synchronizing the password database across systems). If I wanted to avoid paying at all I would have chosen KeePass (which is more a common database format than a single application) which would offer a large number of tools to access my passwords anywhere. Disadvantage would have been finding a way to distribute the database without having conflicting versions.
High-value passwords (business-related or assigned by clients) will be stored in Mooltipass hardware password vault (with astonishingly good support of web browsers in case they are intended to be used there). The password database can be exported for backup but the key for decryption will never leave the device and access to the key is protected by the PIN on the Smartcard. There are copies of the Smartcard as three consecutive failed PIN entries will permanently burn out the card.
My preferred second factor is a Bluetooth-enabled FIDO2 token. If a site does not provide FIDO but is offering Google Authenticator I use an external “computer” (called USB Armory) to generate the code and transfer it to the necessary input field.