It's been done, most notably in IBM/Lotus Notes, but that also brings its own set of problems to the table.
In the Notes system, the user has an encrypted local credential store (part of the ID file) which contains, among other things, the user's private key and any shared secret keys the user may have been granted. The ID file also contains (in the clear) a certified public key, user name, and other information that should not be considered secret. The only password authentication is locally with the ID file. The password is salted and stretched with a key derivation function; the derived key is used to attempt to decrypt the encrypted portion of the ID file. "Success" is determined entirely by padding and checksums. Neither the password nor any variation on the theme of a hash of the password is stored anywhere. The "safe" portions of the ID (username and public key) are used to create a user account on the server.
Authentication proceeds much like this: "Hi, server! I'm this guy according to that guy." "Oh yeah? Well, this guy (if that's your real name), you ought to be able to answer this encrypted question and send me a signed response."
(Determining whether that guy actually vouched for this guy is standard signature stuff, assuming the check is needed at all. For stand-alone clients, a locally-generated certifier is SOP.)
That does raise a couple of potential pain points, though. One is simply managing the local store, making sure that the users always have access to their credentials. Another is that when a store dies, the private key dies with it (secret keys can always be re-issued to a new credential store once the user is satisfactorily vetted). And users have this horrible, horrible habit of either never backing anything up or "backing up" to the same physical medium. In the corporate Notes world, that's not such a problem since updated ID files mail themselves off to an ID vault, but who gets that trust in the civilian world? And there's the little matter of password recovery (in Notes, a KDF state accessible using a combination of something like Shamir secret sharing and the private keys of k of n trusted administrator IDs) — one probably doesn't want to throw recoverable credential stores into the wild hoping that trust is never broken. Without password recovery (which isn't actually password recovery; it simply allows the user to re-encrypt the I with a key derived from a new password they choose) of some sort, anything that requires your private key is lost when your password is lost. Automating the resetting of a server account brings us back into the realm of highly insecure things like "security questions" (since it's very likely these days that the second factor of 2FA is the same lost/stolen device that prompted the need to reset the account in the first place).
In the Notes system, the user has an encrypted local credential store (part of the ID file) which contains, among other things, the user's private key and any shared secret keys the user may have been granted. The ID file also contains (in the clear) a certified public key, user name, and other information that should not be considered secret. The only password authentication is locally with the ID file. The password is salted and stretched with a key derivation function; the derived key is used to attempt to decrypt the encrypted portion of the ID file. "Success" is determined entirely by padding and checksums. Neither the password nor any variation on the theme of a hash of the password is stored anywhere. The "safe" portions of the ID (username and public key) are used to create a user account on the server.
Authentication proceeds much like this: "Hi, server! I'm this guy according to that guy." "Oh yeah? Well, this guy (if that's your real name), you ought to be able to answer this encrypted question and send me a signed response."
(Determining whether that guy actually vouched for this guy is standard signature stuff, assuming the check is needed at all. For stand-alone clients, a locally-generated certifier is SOP.)
That does raise a couple of potential pain points, though. One is simply managing the local store, making sure that the users always have access to their credentials. Another is that when a store dies, the private key dies with it (secret keys can always be re-issued to a new credential store once the user is satisfactorily vetted). And users have this horrible, horrible habit of either never backing anything up or "backing up" to the same physical medium. In the corporate Notes world, that's not such a problem since updated ID files mail themselves off to an ID vault, but who gets that trust in the civilian world? And there's the little matter of password recovery (in Notes, a KDF state accessible using a combination of something like Shamir secret sharing and the private keys of k of n trusted administrator IDs) — one probably doesn't want to throw recoverable credential stores into the wild hoping that trust is never broken. Without password recovery (which isn't actually password recovery; it simply allows the user to re-encrypt the I with a key derived from a new password they choose) of some sort, anything that requires your private key is lost when your password is lost. Automating the resetting of a server account brings us back into the realm of highly insecure things like "security questions" (since it's very likely these days that the second factor of 2FA is the same lost/stolen device that prompted the need to reset the account in the first place).
Nothing's perfect... or easy.