Earlier quoted context omitted.
I remember using a company-mandated pension website which required a very long password with a comprehensive selection of complexity requirements. To log in, the password had to be entered twice, but they had disabled the ability to use a password manager to populate them (I forget the exact mechanism). To me this is the worst of all worlds. If you put people off using your website, you are less likely to have breach…
My broker asks for 4-5 random letters of my password each time, making password managers unusable as well. Thinking about it now, how would you encrypt a password using this method? Create hashes of every combination?
Though, my bank uses a dual-password setup where the first password is required in its entirety and a few letters of the second password are required. I suspect this is stored by using a (hopefully memory-hard) salted key derivation function/password hash function (such as Argon2 or scrypt) to derive an encryption key from the first password, which is then used to decrypt the second password.
At least, that's the way I'd design the system to minimize consequences of database compromise. Users are often not creative and often use related passwords. You'd want all of the stored information about the second password to provide clues to the first password only if the attacker had already cracked the first password. Hashing all of the permutations really blows up storage space and DB I/O.