Public-key cryptography, or asymmetric cryptography, is the field of cryptographic systems that use pairs of related keys.
Each key pair consists of a public key and a corresponding private key.
en.wikipedia.org/wiki/Public-key_cryptography
With asymmetric cryptography, the "password" (your long term private key) doesn't leave your device.
The server sends a new challenge and you compute a solution to the challenge on your device using your private key and send the result and the server has a "recognizer" stored (the public key) that lets it determine whether you have computed something that could only have been computed with access to the private key (a private key that the server has never seen).
Someone seeing your challenge-response pairs cannot compute the response to the next challenge.
This means that an attacker in full control of the server doesn't get to steal your private key.
They might be able to fool you to sign / authorize bad things, but not steal your key, and when the attacker's access is revoked you don't need to roll your key.One of the problems people have when trying to learn about asymmetric cryptography, which you appear to have not even tried to do but I hope you will now try, is that people's intuition about asymmetric cryptography is that the thing it promises to do (and actually does) is impossible.
That a Diffie Hellman key exchange or a digital signature or a KEM are impossible, there must be some trick and there must be some way to just compute the private key from the public key or something.
But no, asymmetric cryptography really does what it says, and you can't simulate that with symmetric cryptography.