Unfortunately, storing the crypted version of the password on the server means that the client has to send the password to the server in plaintext. Either you hide that with SSL, or you accept the fact that you have no real security.

If you try to protect the password in transit by using something like HTTP digest authentication, then you have to store the password (or some equivalent secret information) in plaintext on the server. Which is the bigger vulnerability?

Some excellent points, no_slogan. It's kind of depressing that the current state of the art, as far as anything common enough to be useful goes, relies so much on plaintext passwords. (Although you might be able to get the client to hash the password before sending it over the wire, using a browser plugin of some sort. Provided that you trust the plugin.)

Is there a better way of doing user authentication for sites like PerlMonks out there that doesn't rely on pie-in-the-sky technology? (Preferably something that doesn't involve shared secrets, which IMHO are just too much trouble.) Having the client hash the password before sending it over the wire is a start, but doesn't help much if the server isn't who the client thinks it is, since the attacker can just play back the password hash at the real server.

I'd look up some ideas, but my copy of Applied Crypto is at home, and I'm not. Anyone else?

--
:wq