Again, you can't do anything for idiots who use permutations of dictionary words. "11elephant82" has about 5 symbols worth of entropy. Pathetic.
The world is full of "idiots" otherwise known as people who have better things to do then remember things they are either incapable or lack sufficient motivation to remember.
For a solution to have value to real people in the real world it can only cost as much in time/money/convenience as people are willing to spend/accept.
Decades of experience makes it crystal clear too many people reject secure passwords and nothing we do or say will ever change that... Calling everyone names or blaming users for their poor choice of passwords after a server compromise is not only worthless waste of time that helps nobody but ignores the fact the systems compromise = epic system/administrator failure + blaming the victim. When you get hacked it isn't the users fault so what business do you have asking more of them to hedge against compromise that should not occur in the first place?
If you use a secret key, it needs to be loaded into memory, as does the password database. Guess what?
No shit. You can still create systems with high security with physical separation of concerns. Here is an example architecture:
Application server + database server teaming with millions of reversibly encrypted passwords.
Separate specialized authenticator server with encryption key and separate trust relationship to application server.
User authenticates using zero knowledge proof method... authentication material passed directly from user, thru application stack to authenticator... authenticator looks up password in application database, completes mutual identity verification and sends approval token to application stack.
The only way compromise of credentials occurs in the above scenario is if the authenticator server which does nothing except authenticate is compromised. Even if the application and data stacks are fully compromised user credentials are still safe for all the good that does.
If the key isn't directly accessible, that means that I have to send the encrypted password to a chip and it has to send the decrypted password back. That's plaintext on a wire and in memory. You've already lost. With proper hashing, the password is NEVER in plaintext. You can even run the hash on the client side so it's never transmitted, if you're extra paranoid.
You have it exactly backwards. The authenticator server or hardware only needs to provide a token to the application stack it is not necessary to send clear text passwords anywhere see my example above.
Your example fails because you have three and exactly three options and **NONE** of them work.
1. Send clear text password from user to compare with stored password...This fails as password is required to be transmitted for comparison operation.
2. Use a challenge/response protocol or ship hashes.. This does not work because all such protocols are subject to offline attack while your logging in an easedropper can obtain enough material to run an offline attack and recover credentials.
3. Use a zero knowledge proof of possession to authenticate. This fails because even if you use a hashed password possession of the hash is what is being verified and so having a copy of the hash becomes just as valuable as having a copy of the plaintext.
Alright, I'm through with this troll. Someone else's turn.
Unfortunately in the real world our fairy tales don't get to come true just because we feel empowered to call our users "idiots" and blame them when we ask too much of them or otherwise provide security solutions that are not operationally practical.
My example architecture allows passwords to be only as secure as necessary to prevent *online* attack and clear separation of concerns prevents system compromise from affecting stored credentials regardless of how complex or vulnerable the application and data tiers become.