I am missing something about the usefulness of has

问题:

So, hashes are useful because they change password/login name/salt value combinations to a code that cannot be reversed. The client sends this hash to the server. The server compares the hash to a list of stored hashes to see if the client's user may be granted access. But how do I prevent a malicious user from intercepting the hashed password and writing his own client that sends this hash to the server?

回答1:

Hashes are useful if someone gets a hold of a backup of your database or gets read only access to the live db. They can't then work out the password and send it to your live system. This is why you salt them, so that a hacker with read only access can not set his password and then look to see if anyone else has the same password.

As you have pointed out they don't stop request interception (Man in the middle attacks) to stop that you need to use secure connections with packet encryption and signing. HTTPS & SSL are the most common ways to do this.

回答2:

Thats the Man in The Middle Attack and nothing to the with hashing, to mitigate such attacks we use Secure Sockets Layer and similar technologies.

回答3:

In the case of man-in-the-middle interception being possible a simple solution is a challenge-response protocol.

The simplest form is the following: the user sends his name to the server, the server picks a random number (challenge) and sends it to the client. The client combines the password with the challenge in some predetermined way, hashes the result and sends it to the server. The server does the same - combines and hashes and checks if it has the same result as the client sent.

Each time different challenge is picked and therefore the computed value will be different even for the same password so resending the computed value later will not lead to successful authorization.

It's not necessary to store the raw password on the server - it could store the password hash only and the client could also use the hash and combine that hash with the challenge.

回答4:

No hashes are not used that way. Client first sends password (I suggest SSL is used), server then calculates hash based on that password with salt and compares it to its data in password storage. This way there's no possibility for bad users to get hold of passwords.

回答5:

you use a secure connection to the server and send your password in plaintext over it. the server hashes it and compares it to the hash in the db. the point of hashing is that if the server's password db is compromised, your password cannot be retrieved from it.

回答6:

It depends on the method of interception.

If the user's machine is compromised to the point where malicious software can read their cookies, well, there's not an awful lot you can do.

To stop interception of the network communication, make sure you use SSL (ie HTTPS not HTTP). HTTP is probably most vulnerable at a home or office network, in particular a poorly secured wireless network. HTTPS will give you some protection against a compromised network. This also includes packet sniffers on local networks.

The last option to consider is computers used by multiple people. Internet cafes are one example. Work PCs can be another. You can set a low timeout to minimize the risk of this.

One option some might argue for is IP address filtering, meaning you invalidate the session if you get a request from a different IP. This is a crude approach that is likely to cause more problems than it solves. Basically there are plenty of legitimate cases where a user's IP address will change. Many corporate networks work this way. Wireless roaming including mobile broadband will frequently change IP, particularly when the user is moving (eg on a train).

回答7:

In many systems, the value which is hashed is not static, but uses a nonce each time an action requiring authentication is requested. The server sends a unique value to the client, which is combined with the secret and hashed. This can prevent replay man-in-the-middle attacks.