Earlier quoted context omitted.
No. The server stores salted hashes, and serves the salt and a nonce as part of the login page. The client then submits hash(nonce + hash(salt + pass)). This protects against both replay and rainbow attacks.
I'm a bit confused here. If you were to store salted passwords when you create an account: salt = randomstring(4) hashed_pw = salt + ':' + sha1(salt + password) store(hashed_pw, login_name) How do you then verify this? In other words, how do you send the user the salt and the nonce if you don't know who the user is ahead of time?
Start: User registers for a service and submits a username + password.
The password is salted and hashed in the browser and then sent to the server over a secure connection along with other info. like username etc...
Then when somebody wants to so log in: Server sends a random nonce and keeps track of nonce for all requests when the initial login page is sent to the browser.
Then the user enters username + password to the browser. The browser computes hash(nonce + hash(salt(password))) and sends the result to the server along with username info.
The server looks up the password hash associated with the username and compares hash(nonce + stored-hash) vs. the info. sent by the browser. If there is equality, the user is authenticated and interaction proceeds as normal.
Note that only the user actually knows the password. Even the server only has the hash of a salted version of the password. Next, even this salted hash is never sent directly over the network. A decent implementation will randomize the nonce so that packet sniffing attacks don't work.