Here's a simple idea, based on some reading.
Server stores a hashed version of (plaintext + salt). This avoids passwords being seen, as long as the hash is hard to reverse.
When client attempts login, server sends it (salt,random), ie a constant salt and a newly generated random string.
Client sends back hash(hash(plaintext + salt) + random), ie client appends the salt, hashes, then appends the random, then hashes again.
Server checks that the hashed value is the same as it's own H(H(pwd+salt)+rnd).
I don't have much experience with this, so can I ask what the potential issues are? Also, what does one normally do with the salt? Can you really get away with using the same salt?
The scheme you are suggesting doesn't add any security to checking a password and simply adds complexity that using SSL for login doesn't. With SSL you can safely just transfer the plaintext password from the browser to the server, hash it with the salt, and then check against the stored hash. This eliminates the need for complex schemes. At this time, only nationstates can actually feasibly break SSL connections in a systemic way, although some really enterprising hackers have found some interesting vulnerabilities.
The scheme you are describing sounds very much like a Diffie-Hellman zero knowledge key exchange, which is much more secure than ssl as it never actually transfers the password after it is initially set up with the server. The problem with this kind of key exchange today, is that it must be written in Javascript on the client side and, as such, exposes the actual workings to every attacker that cares to look. The attacker could then just replace your Javascript with something else, or just tap into it to collect the initial passwords if you don't use SSL, so you are again just down to the security of the SSL connection from client to server with only a bunch of added complexity and failure points. There are ways to use ActiveX, Java, or other items to create browser plugins to handle all the key exchange stuff, but this again, adds a failure point for users that will be non-obvious, adds an extra step for the user that other sites don't require (installing the add-on or bookmarklet), and keeps you in development a lot longer for no real benefit.
Firefox has been working on implementing a Diffie-Hellman key exchange for passwords at the browser level, and this, if it ever takes off, will allow a lot of added security and make this kind of password scheme feasible.