But if you're going to use https for registration and store the plain text password, I would prefer to use https on all logins while having the passwords stored in the databaes as salt and pepper hashes.
Challenge - Response is a way to avoid sending passwords in plain text on authentication, I just don't see the advantage over SSL.
My santiments exactly
Challenge-response can be viewed as a "poor man's SSL", it reduces the attack surface as the password never travels in plain text while authenticating. The password (or an attacker-usable derivative of it)
does travel in plain during registration though, hence it's a "poor man's". It's still
much better than nothing, mind you. A salt-and-pepper hashing scheme still transports the password in the clear BOTH when registering and authenticating, so you need to weigh that against the risk of keeping cleartext passwords in the database.
But in the end, as I see it, either your site/application is not very sensitive, in which case it's okay to let the users take the risk of having their passwords sniffed,
or it is very sensitive, in which case nothing less than TLS is suitable. There might be some middle ground between the two, plus there is the argument that users are dumb and reuse their passwords, yadda yadda, but in general it's only these two options.
(*) There might be a way to do the registration with some kind of password verifier that is not the cleartext password, but the argument still stands.
----------
P.S.
Hmm, I think there is a way to avoid keeping the password in the clear:
On registration:
The server generates a random salt and sends it to the browser.
The browser takes the password, hashes it with the salt and sends it to the server. The hash and the salt go to the database
On login:
The server sends the challenge nonce plus the salt
The client hashes the password with the salt (should be the same as what's in the database), then hashes the result with the nonce
The server reads the password hash, hashes it with the nonce and compares the final hash with what the client submitted
In that way the server keeps the passwords salted, but there is still not 100% security against sniffing:
If the attacker sniffs the *registration*, he will not have the cleartext password, but will have the *salted* hash. He can use the salted hash in the challenge-response to impersonate the user.
So it's a reduction of the attack surface, but still not complete security.
With that scheme, the challenge-response becomes equivalent (in what's in the database) to a salted password scheme, with a somewhat better security in the transport part.
There doesn't seem to be an easy way to include a site-specific peppper though, so if that's important to you, you must weigh the options.
----------
Postscript aside, my argument still stands. For most cases it's two options: either use TLS or transport the password in the clear.