No where electronically. A simple word or phrase in the user's mind would do.
Rather than being stored for later retrieval, complex passwords could be generated on-the-fly (when needed) using this word/phrase as input combined with other input such as URLs, hostnames, service names, etc.
That's hard to manage outside of a few specialized environments where you have total control of the user and applications. The problem which comes to mind is that there's no way to use that system when so many sites have incompatible restrictions on length and character set – i.e. I have accounts on systems where the minimum password length is longer than the maximum somewhere else – and I'd still need a manager to track my random answers to security questions.
Rather than trying to make small improvements in the inherently-limited password model we should be focusing on changing the model entirely to depend less on what a human can comfortably remember: that's things like SSO to avoid the need to manage hundreds of accounts and also things like U2F to use strong public-key encryption.
IIUC, you're talking about using what amounts to a user-managed password-generation schema. This seems like a weak (re: entropy) and ultimately very user-hostile approach to password management. Having known people who use such approaches, they still have to remember at some potentially distant time just what cocktail of fields they used in their password formula for this site. That is, the burden of password memorization remains but they don't gain much for their trouble.
I hear of such schemes from time to time but I've never seen them subjected to real attack analysis. I strongly suspect that these mostly generate surprisingly weak passwords.
What is fundamentally different between your suggestion and an approach where passwords are kept in a file that's encrypted with a password that's kept only in the user's mind?
In both cases you have a bunch of data that mostly represents the passwords, but you need one final component to actually unlock it, which is the master password. What's the advantage of your proposal?
You method would require that pass everytime a password is fetched or generated. Similar to the UAC confimation on Windows. Remember how annoying that was, everyone turned it off.
The problem with this is that different passwords have different requirements, which must now be remembered and entered every time you need that particular password.
I suppose "immutable state" would be a nice compromise, but the method is fundamentally less flexible than something with state.
