Is there a reason that one doesn't use a public-key encryption function with a unique, random public key per password to store the scrambled passwords? One would then store the public key and the encrypted password as md5crypt stores the salt and the hashed password.
This is of course not run-time configurable to increase the computational complexity of the password scrambling, but besides that, what are the problems? (I assume that there must be some, since I haven't ever heard of anybody handling passwords this way.)
Does this imply the client doing the encryption? I.e. the client creates a key pair and sends the public key to the server?
It sounds good but the challenge, as always, is the infrastructure. I think it would be great if I had a single personal private key from which I could issue chained keys for each ___domain where I have an account. But imagine managing this across desktops, browsers, phones, game systems, etc. ...
My intent was that the server should still be responsible for scrambling the password as usual. - My question is only about changing the algorithm server-side.
This is of course not run-time configurable to increase the computational complexity of the password scrambling, but besides that, what are the problems? (I assume that there must be some, since I haven't ever heard of anybody handling passwords this way.)